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

[Rick Bradley <roundeye@roundeye.net>]

* 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.