OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] many-to-many

[ Lists Home | Date Index | Thread Index ]

Tim Bray wrote,
> Miles Sabin wrote:
> > Tim Bray wrote,
> > > I think the whole system, both the everyday Web and the Semantic
> > > Web, has a design assumption that a URI identifies something.
> >
> > Maybe, but is that "something" a Resource in the RFC 2396 sense?
>
> Absolutely, beyond any shadow of doubt.  2396 says a resource is
> anything that has identity.

I think one sign of the usefulness of the "REST is just one view among 
many" attitude is that I no longer feel compelled to object to the 
details of this definition. That's a win IMO, because frankly I'm bored 
with it.

Now I'm just compelled to object to this definition being foisted on me. 
If it works for you, fine, but get your tanks off my lawn.

> > As far as network protocols and software are concerned, abstract
> > Resources do no work at all. What matters in a retrieval context is
> > that there be a functioning server that's capable of returning a
> > response, maybe with a response entity, maybe without.
>
> Wrong.  The vast majority of software interactions with URIs - in
> browsers and web robots - involve no network traffic; rather the URI
> is used as a string to lookup an entry in a cache or proxy or spider
> state machine or whatever.  This is a direct function of the
> assumption that the resource is the abstract whatever identified by
> the URI.

I disagree. Abstract Resources aren't needed for HTTP caching. Nothing 
would break if you thought of it as operating in terms of entities with 
URIs telling a cache where to go to get a fresh entity when the current 
one is stale.

And it's worth noting that most search engines handle "resources" which 
move (ie. are no longer retrievable via an earlier URI). On the REST 
orthodoxy this makes no sense at all ... so much the worse for REST, 
I'd say.

> > So, if there were no Resources, or more than one, or different ones
> > on different occasions, what would break? Can you name one piece of
> > working software that'd stop working if Resources were to vanish in
> > a puff of existential smoke overnight?
>
> Well, if you talked only about URIs and representations I agree, the
> web would hold together,

That's what I'm suggesting, at least at this level of abstraction. 
Actually, I'd go a little further. "Representation" is now almost as 
weighed down with REST baggage as "Resource" ... so I'd rather just 
talk about URIs and entities (in the MIME/RFC 2616 sense).

> but it seems to me that not thinking about what URIs identify is an
> artificial constraint; sure, you can pretend not to know what the
> letters stand for in URI, but do you really feel happier as a result? 

Yes, because I'm now free of the artificial constraints imposed by REST. 

I can now assign higher-level denotations to URIs which make sense for 
the particular concrete case at hand, even where that conflicts with 
the REST orthodoxy. I can, for example, make sense of URIs with no or 
with multiple interpretations (handy for RDF and a lot else besides), 
or things which move or are replaced (handy for just about every web 
site in existence) without having to struggle to reconcile the way 
things actually work with the way REST says they're supposed to work.

Cheers,


Miles




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS