- From: Gavin Nicol <gtn@ebt.com>
- Date: Thu, 2 Jan 1997 08:29:31 -0500
- To: dgd@cs.bu.edu
- CC: w3c-sgml-wg@www10.w3.org
>> /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 > URLs. 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 >within them. 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 >>it do?). > >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!!
Received on Thursday, 2 January 1997 08:31:21 UTC