Re: Recent ERB Work on URL addressing

Gavin Nicol wrote:
> 
> > Summary: the ERB is leaning *very* strongly to asserting that all
> > locators are to be URLs - and will almost certainly go this way, if
> > we aren't thereby throwing away our nice clean international
> > interoperability.  Input welcome. - Tim
> 
> The problem with URL's is really 3 problems rolled into one:
> 
>   1) Naming
>   2) Addressing
>   3) Queries
> 
> If the ERB emphasizes that URL's are to be used for (2), then this
> will be fine. Once we get (1) and (3) mixed in, URL's become an
> unholy mess.

This was a question I asked Tim.  He told me that there shouldn't 
be this distinction in the spec per se.  I agree;  this looked 
to me like a way to handle the implementation under COM, so it's 
a discussion that probably belongs on the developer's list;

>Tim, if someone were using a structured storage server (storages 
>and streams in a compound document), would it not suffice for the 
>XML client to send that server the request, have the server unpack 
>what it needs from the compound document and return it as a file?
>In that case, the URLness of always getting files is unbroken and 
>the subdocument/subelement addressing is something only the 
>server cares about.  Would that work?  The bad news is the 
>server stored files are fatter and there is overhead.  Also, 
>since the structure storage definition only contains streams 
>and no record level management, the application server has 
>to handle that and enforce it. Maybe an XML definition or requirement
>for the XML server is needed.

I agree with what you are saying above, but that has always been 
the case with URLs as far as I know.  Watching some of the 
discussions on the uri list, it seemed that trying to get the
naming and addressing concepts into separate boxes was a fairly 
difficult problem.

len

Received on Tuesday, 18 March 1997 13:48:05 UTC