- From: Simon St.Laurent <simonstl@simonstl.com>
- Date: Tue, 16 May 2000 19:18:46 -0400
- To: <xml-uri@w3.org>
At 05:53 PM 5/16/00 -0400, Tim Berners-Lee wrote: >One example, given by Chris Lilley I think, from WebCGM experience, is that >of a schema which defines a language and sees it in the same document in a >deliberately (not accidentally) self-referential way. [The C program module >parallel would be a program file which defines a number of functions, and >makes calls to those functions within the same file which defines them.] >For example, the schema for schemas could bootstrap itself into existence >referring to itself as "#". I'm not sure I see where this is either useful or meaningful, except as a convenience to the editor. Perhaps it's an extremely explicit version of Walter Perry's 'every document on its own terms', but I'm not sure that namespaces are necessary or even useful in such a case. The schema for schemas might be a lot smarter to bootstrap itself with an explicit reference to a fixed version. >Another example is a suite of schemata which define interrelated languages, >so that for example a Shape-based Vector Graphics and a Spline Vector >Graphics and Spatial vector Graphics schemata are published as a trio and >use each other's namespaces. he editor just finds that editing the three >documents is easier with relative URIs as it is always important in the >various drafts and versions and branches of discussion that the three >schemata refer to each other, and it is really burdensome and error-prone to >have to change the namespace declarations whenever a different variety of >the specs is produced. Again, I don't find this convincing. 'Editing with relative URIs' is always easier, _if_ you're tracking the URIs manually. If you're really running a project like this, I'd strongly suggest that you're well past the point where using convenient shortcuts is a good - or safe - idea. >So there we have two made up examples - they exist. Are we to be able to >predict the uses of XML namespaces so clearly that we can guarantee no more >will arise? Are we willing to sanction a usage in which it's quite clear that users can change vocabularies through actions (like copying files) that normally have no such side effects? (Heck, I don't get to sanction anything.) >(Examples have also bee quoted in other fora of software which accepts >relative URIs and documents which have been written to take advantage of >that fact.) The existence of those examples has not yet been demonstrated. >If you find these two unlikely, then that is still not a reason to ban >relative URIs. There is also the argument that says that really people are >in fact extremely unlikely to misuse this feature because almost all >namespace names will be absolute (as there will be no common root with the >document base address anyway). In any event, I'll be adding large WARNING notes to every one of my XML books suggesting strongly that users avoid this so-called feature. Sadly, my books are becoming festooned with such warnings as the interactions between XML 1.0 and itself and XML 1.0 and namespaces become clearer. (For examples, see either my book XML Elements of Style, Part 4, or the Common XML draft spec at http://www.simonstl.com/articles/cxmlspec.txt, which is pretty much a list of such warning labels.) >But if you ban them, you move from a situation in which there are two >concepts in the grammar, a URI and a URI reference, to one in which there >are three: a URI, a URI reference, and a URI reference constrained to be >absolute. The last does not exist in the grammar at the moment. Defining it >complicates life. Any agent which processes XInclude and/or Xlink or xHTML >must anyway have the concept of a URI reference. Most software which does >anything, including XPath and XSL to take recent examples, must be able to >handle relative URIs. So if you imagine that saving the hassle of >absolutizing a URI reference will simplify the code - then what happens when >your code hits an XInclude? Do we have the whole argument all over again? >It is much easier to think of likely examples for XInclude. And XInclude >processing is also crucial to the integrity of a document. You are going to >have to have the base URI available in fact, and avoiding using it for >namespaces just puts off the question until the next layer of code. I'm not sure that everyone in this discussion considers XInclude and XBase to be a good idea. Creating a URI reference constrained to be absolute doesn't seem like a horrible sacrifice. >Those are some counter arguments as I see it. I could *imagine* living >with the banning of relative URIs in order to allow base-URI-awareness >(including XInclude processing etc) to be moved a level above the DOM, >leaving the DOM base-uri-unaware is it is proposed. (I think such an >architecture is broken, as I believe that XInclude processing should take a >document at one level of abstraction and yield document at the same level of >abstraction.). Banning relative namespace URIs could be a compromise. I can imagine living without the banning of relative URIs, but I think at some point we'd have to give up on the fable of interoperable and reliable markup applications. We've been headed that direction for a while, so it may not be so great a sacrifice. Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. Building XML Applications Inside XML DTDs: Scientific and Technical Cookies / Sharing Bandwidth http://www.simonstl.com
Received on Tuesday, 16 May 2000 19:16:47 UTC