Re: URLs/MIME only?
At 8:29 AM 1/2/97, Gavin Nicol wrote:
>>The location mechanisms we are referring to (element addressing, etc) are
>>essentailly XML specific (but necessary, despite all that). So it makes
>>sense that the XML browser should be responsible for locating the sub part
>>of a document. The WWW has taken several positions that affect this:
>> 1. A URL is the finest granularity of object that HTTP and browsers
>> are required to deal with.
>> 2. That any kind of semantics in a url that is client interpretable
>> shall only be related to protocol negotiation.
>> 3. All other semantics in a URL are server-only.
>> These positions are slightly modified by # strings:
>> 4. A client gets an opaque address inside a # string that can be
>> interpreted to find a sub-part of the addressed resource,
>> possibly based on the MIME type of the resource.
>> This severely handicaps our position with respect to adding locators to
>Why? I think this depends upon whether you see documents or
>(p)elements as the atomic objects. I think there is a *very* strong
>strong case for looking at elements as atoms, especially when we start
>thinking about transclusion etc. We can build an awful lot upon the
>two forms above in a *simple* and *standard* way.
The problem that I see is that HTTP and current implementations make a
pretty strong URL<->transmission unit equivalence. XML has a notion of
transmission unit that is a natural one, and that is the entity. So we are
making entities into findamental addressable units. Now we could also make
elements into addressable units, but doing so makes some pretty hard
requirements on servers, if those URLs are to be resolvable. Now I agree
that a dynabase-like approach is the "right" way to build sophisticated
servers, but I think the demands of document parsing, etc. that are
entailed by making that approach mandatory will prevent the implementation
of the lightweight, quick-hack servers that have driven the evolution of
So, I agree that we can do as your ask, if we make elements into the
base level of structure. But I disagree that we can expect most server
implementors to implement XML servers if they have to implement this kind
of sub-element addressing.
>Points 2-4 are red herrings, and fall out of point 1.
They may not be logically independent, but I don't think they are
red-herrings, either. Doing as you ask requires a rather different model
from the one we have been implictly using:
XML entities <-> URLs to access them
XML elements must be parsed to be detected.
>I do *not* consider these to be XML specific: they are just
>tree/list-of-lists-specific (a list is a degenerate tree, or a tree is
>a list-of-lists POV). This is certainly no worse than current URL's.
Yes, but it prevents the "slap XML files into an existing server, with a
new mime type" deployment apporach. It may be one hell of a convoluted noun
phrase, but it is going to be a common implementation strategy.
>> I have never seen these position articulated in exactly these words,
>>but the intent is very clear from conversations I have had with Dan
>>Connolly, Hernik Frystyk, and other W3C notables. I don't necessarily agree
>>that this is a necessary set of restrictions, but I think we can live
>I've dealt with all these folk too (and more!), and again, I think
>that if you look at elements as atomic, all conditions are met.
>>>I was talking to someone who is planning to implement XML the other
>>>daya, and there is already misunderstanding about what that PI should
>>>do (ie. can it occur in places beyond the header, and if so, what does
>>I think it can occur anywhere and do anything, right?
>God forbid. That would (logically) mean that you could switch encoding
>mid-stream... which is precisely how this fellow interpreted it!!
Unless I'm wrong, PIs are still legal in XML in general, and they are
unconstrained as to functionality: (though we might want to state that PIs
_cannot_ change parsing behavior, if we don't already). So he might even
_have_ a conforming extension to XML, albeit a pretty vile one.
I am not a number. I am an undefined character.
David Durand firstname.lastname@example.org \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________