Re: URLs/MIME only?
>> /foo.sgm/4/2/99 - Child numbers
>> /foo.sgm/chap=1/sect=2/para=45 - Typed children
>>This is easy to read, understand, and is useful for things like
>>addresses in OODB, and RDB as well.
>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.
Points 2-4 are red herrings, and fall out of point 1.
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.
> 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!!