RE: [syndication] site-wide metadata [was: RFC: myPublicFeeds.opml]

["Danny Ayers" <danny666@virgilio.it>]

Thanks Rick, wish I'd said that ;-)

> -----Original Message-----
> From: Rick Bradley [mailto:roundeye@roundeye.net]
> Sent: 15 October 2003 23:01
> To: syndication@yahoogroups.com
> Subject: Re: [syndication] site-wide metadata [was: RFC:
> myPublicFeeds.opml]
>
>
> * Dave Winer (dave@userland.com) [031015 14:14]:
> > 2. The train left the station on this with robots.txt. The
> world survived.
> > Sorry, I noticed. I wasn't supposed to, I guess, but I did.
>
> The robots.txt convention is not scalable, addresses a different
> population, and was a punt at a time when most of the future use cases
> we're now addressing were unimaginable.  It's like pointing to chariots
> as a best practice when proposing a way to increase fuel efficiency in a
> new car.
>
> > 3. Instead of impeding growth, it would be great if the W3C did
> things to
> > foster growth,
>
> Last I checked the W3C brainstorms a lot and issues recommendations.
> One can follow said recommendations or choose not to.  I don't see how
> the W3C is impeding much of anything in that manner.  In fact the amount
> of positive growth on the Internet is staggering.  Methinks you're
> confused.
>
> > like declare one top-level name to be reserved, and then establish a
> > web app to reserve names within that folder. It would take a weekend
> > to write and deploy. I'll help.
>
> I don't understand how issuing a recommendation that serves little but
> to further your misguided discoverability scheme is "foster[ing]
> growth".  Noone is stopping you from writing and deploying anything --
> in fact I'm firmly convinced it's impossible to deter you from doing
> whatever you please, protestations of impedance notwithstanding.  A
> number of us are concerned that your connections with Userland
> (disclaimers aside) and their history of adopting strongly-pushed
> weakly-considered designs from time to time, will result in widespread
> adoption of another bad idea.
>
> > 4.Further, only optional functionality should depend on these
> names, nothing
> > mission critical (as previous applications have done).
>
> Robots.txt, and favicon.ico represent optional non-mission-critical
> functionality.  They are also conventions imposed by lack of design, and
> as designs will not scale as prototypes for discoverability services.
>
> It is one thing to look at an early punt (robots.txt) and say "hey we
> survived that", or at a monopolist's feature extension (favicon.ico)
> with no concern for the impact of their poor design on the Internet and
> say "see, there's another example"; but in this age, where we should not
> plead ignorance, shoving a single file in the *server's* DocumentRoot is
> poor planning, poorly scalable, and makes no consideration for future
> use cases.  In fact it makes little consideration for current use cases.
>
> Some people will push a bad idea relentlessly because it's expedient for
> whatever quick hack they're trying to push at the moment.  For my small
> part, as things stand with discoverability:
>
>  - Yes, I could implement some /foo.opml file dynamically, even going so
>    far as to serve up different content based upon agent, referer, host,
>    and source information, and maybe be able to then partition
>    user/category/application-specific feeds, but it would be working
>    *against* the designed discoverability system, not with it.
>
>  - But I won't, because it's a broken design being pushed for no clear
>    good reason.  I'll either use the format and just <link> it or I'll
>    support a different standard altogther (there's almost certainly
>    going to come an RDF standard if this OPML+/foo.opml monstrosity
>    escapes the womb).
>
>  - And I'll go a step further and probably devnull requests from IPs who
>    ever go-a-fishing for such a file -- their software's poorly designed
>    and is no concern of mine, let the users complain upstream to their
>    boneheaded vendor.
>
>
> I can sum up my opposition to the discoverability scheme under question
> in two points:
>
>  1 - Don't go fishing.
>
>      Robots.txt is /tolerated/ because Google is a good thing.
>
>      Favicon.ico is widely regarded as an annoyance by everyone who
>      understands what it represents, even by some who play the
>      favicon.ico game ("what, one icon for the whole domain???").
>
>      With each default file that propagates into the consensus standard
>      stream there is more incentive for someone else to not think
>      through the consequences and add yet another.  Eventually everyone
>      will assume that the Right Way to standardize discovery is to look
>      for some file in / (or /w3c or /default or all the way up the URL
>      path to the root).  Pretty soon you've got so many possible things
>      that could be on your server that you're getting more hits for
>      discovery than you are for documents -- AND THERE'S NO WAY TO OPT
>      OUT.
>
>      The only way to stop this descent into discoverability hell is to
>      stop it before it really starts.
>
>  2 - There are unrecognized use-cases which will break.
>
>      Many of the stakeholders in web language standards are stakeholders
>      precisely because they're well-entrenched in the current paradigm.
>      The current paradigm knows websites in the 1-server 1-site model or
>      the 1-user 1-site model.  The current paradigm knows "blogs" where
>      there is a "page" that has a linear list of content items.  In both
>      of these paradigms the notion of a single file per domain may be
>      stretchable, but it's already at the stretching point as people are
>      breaking the website and blog mold.  (The bulk of current interfaces
>      are also hierarchical at the URL level.)
>
>      From a technical perspective there is very little that is
>      interesting about a website these days.  Similarly, there is very
>      little technically interesting about blogs these days.  In fact,
>      blogs are boring, wikis are boring, websites are boring (and all
>      have been for at least a couple of years now).  They're boring like
>      light bulbs and microwave ovens -- useful and once novel, but now
>      merely utilitarian.
>
>      Designing for the current predominant use cases is (a) designing
>      for the boring, and (b) designing for quick obsolescence.  We have
>      to make sure not to break things, but we should be designing
>      something that will at least be useful next year.
>
>      A couple of things that don't fit with the /foo.opml
>      discoverability scheme but which are (or have been) interesting:
>
>       - graph-based content architectures:  The notion of a "page" (or a
>         site) is, frankly, too limiting (and too unimaginative), of
>         linear content lists is simplisme, of having some limiting
>         document specify layout is silly.  View content as nodes in
>         graphs, with edges representing certain relationships between
>         reusable content.
>
>         4 years ago I worked on a system where content could be reused
>         across a set of Internet domains (e.g., you could transparently
>         access objects visible on foobar.com on barfoo.com, presuming
>         they were hosted on the same server -- syndication between
>         servers would be straightforward but was never developed), and
>         arbitrarily repurposed: select a graph from the repository and a
>         starting node, choose a set of rendering widgets, and view the
>         rendered content defined by a graph traversal.
>
>         You can apply a REST interface to such a system but the notion
>         of a nested hierarchy of URLs didn't particularly fit, and the
>         thought of having a single index of feeds (which are just
>         renderings of graphs from certain starting points) at the / of
>         every participating domain is a non-starter.
>
>         The way one might build this now has changed dramatically:  XML
>         databases, XML fragments for nodes, RDF for edges, XSLT for
>         templates, REST and/or web services for manipulating the
>         repository, RSS et al. for syndication, etc.  But the
>         applications are still compelling, and the incongruity with this
>         discoverability scheme still significant.
>
>       - Convergent applications:  I feel the "place" where I store
>         information for my use should be the same "place" where I store
>         information for public consumption, which should be the same
>         "place" where I access applications that work with my data.  I
>         have a web-based jukebox system whose data I am now adding to an
>         XML repository, along with other unrelated data I am bringing
>         online and across-online (if you will).  The new player
>         interface (a player client downloads a playlist to play or
>         stream from its location) will just use RSS feeds to list songs
>         to be played.  Those feeds would be listed where appropriate,
>         but wouldn't be listed with feeds related to (say) recent
>         publications, or recently read news related to Linux.  Feeds
>         come and go as players come and go.  Public feeds may be
>         usefully discoverable, while private feeds would not be.
>
>         It's doubtful that the interfaces to these various applications
>         will be organized hierarchically (some of the accesses may be
>         simply through XPath+XSLT), so /foo.opml-type discoverability is
>         going to be a waste of time.
>
>     These may not be the most concise use-cases, but they represent real
>     directions different from the overdone blog+website world that we
>     appear to be designing for (or in the case of /foo.opml the static
>     webpage and tacky animated-GIF world we'd be designing back to).
>
> > That's about all I want to say on this. I've noticed how much
> effort one has
> > to put in to innovate here. This mail list is broken. Sorry, I
> forgot. ;->
>
> Meditation on the causes of purported brokenness is suggested.
>
> Rick
> --
>  http://www.rickbradley.com    MUPRN: 747
>                        |  it, and that is the
>    random email haiku  |  key to passing things into
>                        |  long term memory.
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>