- From: James Clark <jjc@jclark.com>
- Date: Sat, 24 Jun 2000 12:01:21 +0700
- To: Dan Connolly <connolly@w3.org>
- CC: xml-uri@w3.org
Dan Connolly wrote: > So regarding a doc at http://example.com/dir1/dir2/ > <aDoc xmlns="../foo"/> > > Q: does it conform to XML 1.0? > A: of course; noone has suggested otherwise. > It's well-formed. > > Q: does it conform to the namespaces spec? > A: indeed, it does. > But if you look at the errata page, you'll > notice a big warning that you're asking > for trouble by using relative URI references > in namespace declarations. A namespace processor has to compare namespace names for identity to enforce the rule on attribute uniqueness. Does a namespace processor compare names literally (without regard for base) on this proposal? > Q: OK, then, what's the namespace name of the root element? > A: ../foo , per the namespaces spec as written. > > But be careful about calling it anything else, > like "namespace URI" -- that terminology suggests > that you're talking about the absolute form > of ../foo w.r.t. the relevant base. I don't buy that. I don't think "namespace URI" is any more suggestive of the absolute form than "namespace name". > Q: In the infoset, what's the value of the in-scope-namespaces property > of the root element? > > A: unspecified; out of scope for this version of the infoset spec > > The infoset spec not only doesn't cover documents > that are well-formed but not namespace-spec-conformant, > this version doesn't cover documents that > are namespace-spec-conformant but use relative URI > references in namespace declarations. That seems like a non-solution to me and a waste of all the effort that has been put into this discussion. > (as Paul G put it: > 2. say that a document containing an nsattrib whose value is a > relative URI has no defined infoset.) > > Q: what does the DOM spec return for the namespaceURI attribute? > > A: unspecified; > (see elaboration by Joe K above) > > Q: what's the value of the XPath namespace-uri() function > with <aDoc> as the current node?? > > A: http://example.com/dir1/foo per the XPath and URI specs, > but beware: we've seen implementations that don't > give that answer. The key issue is what's in the XPath data model. That determines how names are matched for identity. If you're implying that XPath determines name identity using absolutized names, then you're proposing that the XPath Rec and the Namespaces Rec simultaneously use inconsistent methods for determining name identity for a particular namespace name. I find that completely unacceptable. Either: a) the data model should say it's undefined consistently with what you are proposing for the infoset and the DOM; or b) the data model should contain the unabsolutized name, thus ensuring that the XPath Rec compares names consistently with Namespaces Rec Note that XSLT tracks the base URI and automatically absolutizes when you use a relative URI to access a resource with the document() function. The only case where this breaks down is if an external entity inherits namespace declarations from the referencing entity and it has a different base URI. One could add complexity to make this case work too, but it doesn't seem worthwhile to me. Things will work quite nicely if namespace-uri() returns the unabsolutized URI reference, and this also matches the behaviour of the overwhelming majority of deployed XSLT implementations. > [I'm sympathetic to the suggestion > to deprecate the namespace-uri() function > in favor of separate raw-namespace-decl-attr-val() > and absolute-form-of-namespace-decl-attr-val() functions; I'm not sympathetic. Why add complexity just to deal with a deprecated case? > I'd certainly like to see uri-expand(base, uriRef) > and uri-relative-with-respect-to(here, there) > utility functions added to XPath/XSLT document() has this functionality built in, but it would be sometimes be useful to have it available separately as well. James
Received on Saturday, 24 June 2000 01:05:12 UTC