- From: Dan Connolly <connolly@w3.org>
- Date: Thu, 29 Jun 2000 15:11:57 -0500
- To: James Clark <jjc@jclark.com>
- CC: xml-uri@w3.org
James Clark wrote: > > 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? Yes (details in my reply to Henry of Tue, 27 Jun 2000 08:10:00 -0500). > > 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". I maintain that it is not just suggestive; it is the standardized usage of the terms "URI reference" and "URI": ========== excerpt from http://www.ietf.org/rfc/rfc2396.txt 4. URI References The term "URI-reference" is used here to denote the common usage of a resource identifier. A URI reference may be absolute or relative, and may have additional information attached in the form of a fragment identifier. However, "the URI" that results from such a reference includes only the absolute URI after the fragment identifier (if any) is removed and after any relative URI is resolved to its absolute form. ========== That makes it quite clear that the URI denoted by the URI reference xmlns="../foo" in a document whose base URI is http://example.com/dir1/dir2/ is http://example.com/dir1/foo and strongly suggests that something called "namespace URI" should be http://example.com/dir1/foo as well. > > 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. I can understand not being fond of it, but I don't see compelling evidence that it is a non-solution. > > (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 am merely observing that this is the case, not proposing it. > I find that completely unacceptable. Yes, well, that's why we're here, I suppose... > 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 I was hoping to avoid re-issuing the XPath spec, but I suppose I am compelled to agree that (a) saying that namespace-uri() is undefined in this case is necessary for consistency. I find (b) to be unacceptably inconsistent with the URI spec excerpt above. > 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. I don't understand how namespace declarations are relevant to the document() function. I think I don't understand this paragraph at all. Would you please elaborate? > 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 don't think I understand this either. Which things? > > [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? This situation where the spec says one thing and the implementation says another reminds me of times when I have been writing large pieces of software, and while writing one part of the program, I was thinking that func42() did one thing, but while writing another, I was thinking that func42() did another thing. Luckily, the mismatch manifested itself at runtime, and I discovered the bug. The only way I could restore my confidence in the program as a whole was to change the name of func42() and revisit every reference to it to check for consistency. Another way of looking at it: somebody who grabs a W3C recommendation and implements it doesn't have any obligation to check back every once in a while to see if we've changed it out from under them. So for all we know, there are XPath implementations that match the spec as written. I think it's anti-social to invalidate those implementations. That's why I'm sympathetic to garbage-collecting the namespace-uri() function name. But I could be convinced that the risks associated with just pretending that the XPath spec never said to absolutize are sufficiently small that we should just revise it "in-place" (i.e. using the same names). > > 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. We agree on that, at least ;-) -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Thursday, 29 June 2000 16:22:13 UTC