- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: Mon, 03 Jul 2000 19:48:09 -0600
- To: xml-uri@w3.org
Participants in this discussion will be aware that in addition to the active discussion on this list of the technical issue on which this list is focused, there have been extensive discussions within the W3C, as well as outside it, on the ticklish question of how to move toward a resolution of the question. The most recent development in the search for a resolution is outlined in a message to the W3C XML Plenary discussion group, from its chairs (i.e. from us), which is appended. The results of the question put to the plenary will be summarized to this list, after the close of the polling period. -C. M. Sperberg-McQueen Dave Hollander Co-chairs, W3C XML Plenary Interest Group -------------------------------------------------------------- Date: Mon, 03 Jul 2000 17:31:16 -0600 To: w3c-xml-plenary@w3.org From: "C. M. Sperberg-McQueen" <cmsmcq@acm.org> Subject: relative URI references in namespace declarations As members of this group will know, all the working groups in the XML Activity, as well as many individuals in the Web community at large, are currently bedeviled by the problem of how to interpret namespace declarations whose values take the form of relative URI references. In spite of the earlier discussion of this in the XML Plenary, the straw poll taken by the XML Plenary in April, and a month of discussion on the xml-uri list, we have not yet resolved the issue. A number of specifications are in limbo, unable to move forward until we as a consortium reach a commonly accepted decision on this question. In the long term, we believe most people would agree, the consortium needs a clear and coherent approach to the complex of problems of which the 'relative-URI-reference-in-NS-declaration' problem is a visible example. In the short term, we need an approach that everyone can live with, that avoids foreclosing later long-term solutions as far as is possible, and that will allow the various specs now in limbo to move forward. Recent discussions in the xml-uri [XU] list suggest that a proposal originally made by Joe Kesselman [JK] and then elaborated by others [DC] may provide an approach everyone can live with. We are grateful to all those who have participated in the effort to clarify and resolve this issue for their work. If everyone, or almost everyone, can live with this solution, at least for the short term, then it may break the logjam. Some members of the XML Plenary have requested that we, as chairs, ask the Plenary to consider this question again, and see what kind of consensus we now have on this issue. [XU] http://lists.w3.org/Archives/Public/xml-uri/ [JK] http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0379 [DC] http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0854 Since a resolution of this problem seems to grow more urgent by the week, we believe the progress of the XML Activity will be best served if we put the question to the XML Plenary. The technical content of the proposal is outlined below. Since it is clear that there is not now unanimity on this question, we have agreed with the Director and management of the W3C that it is desirable for us to put the question to a vote in the Plenary. If the Plenary decides in favor of the proposal, Working Groups preparing new specs will be advised to make those specs agree with the Plenary decision. (As always, the final decision on what a WG does rests with the WG, not with the Plenary: the Plenary decision is only advisory.) If the Plenary does not decide in favor of the proposal, the status quo will remain unchanged. We will send, in a separate message, a ballot to the XML Plenary list, asking each member organization to indicate whether the organization finds the technical proposal outlined below acceptable or not acceptable. Free-form comments on the question may also be included, providing a rationale for the ballot. Ballots are to be returned to the address specified on the ballot, by the time indicated on the ballot for the close of balloting. The chairs will hold that the XML Plenary has decided in favor of the proposal if (a) at least half the qualified organizations cast a ballot of 'acceptable', and (b) at least twice as many organizations cast ballots of 'acceptable' as cast ballots of 'not acceptable'. Organizations may also vote to concur with the majority, in which case their ballots will be counted with the majority. Any organization which is represented on any of the following Working Groups as of 1 July 2000 may cast a ballot on this question, as may invited experts serving on these WGs: XML Core, XML Linking, XML Schema, XML Query, XSL, DOM. One ballot will be counted per organization. If conflicting ballots are received, without clarification, the chairs will count the organization as having abstained. -C. M. Sperberg-McQueen Dave Hollander Co-chairs, W3C XML Plenary IG ------------------------------------------------------------- PROPOSAL ------------------------------------------------------------- Proposed: to deprecate the use of relative URI references in namespace declarations; that is: to say that while they conform to the Namespace Recommendation of January 1999, later specifications such as DOM, XPath, etc. will define no interpretation for them. In particular, regarding the following documents, one at http://example.com/pathSeg/thisDoc.xml : <a:aDoc xmlns:a="../foo" xmlns:b="http://example.com/foo" a:a='1' b:a='2'/> and another at http://example.org/pathSeg/thatDoc.xml : <aDoc xmlns="../foo"/> Q1: do they conform to XML 1.0? A1: Of course; no one suggests otherwise. They are both well-formed. Q2: Do they conform to the namespaces spec? A2: Yes. However, both documents use relative URI references in namespace declarations, which is deprecated. The XML Core WG is advised to publish a notice (perhaps at http://www.w3.org/XML/xml-names-19990114-errata) that the use of relative URI references in namespace declarations is deprecated. Q3: But I thought that ../foo and http://example.com/foo meant the same thing in the context of the base URI http://example.com/pathSeg/thisDoc.xml A3: Even though per RFC 2396 the relative URI reference "../foo" denotes "http://example.com/f" in the context of the base URI "http://example.com/pathSeg/nsDoc.xml", the namespace recommendation associates the prefix 'a' with '../foo', the un-expanded URI reference that occurs in the namespace declaration. Q4: OK, then, what's the namespace name of the root element in thatDoc? A4: ../foo , per the namespaces spec as written. But be careful with terminology. The 'namespace name' is '../foo', but the Namespaces Rec doesn't define a term 'Namespace URI'. According to section 4, URI References, in RFC 2396, "the URI" denoted by "../foo" is http://example.org/foo -- and terms like "namespace URI", which allude to that mechanism, should be used with great caution. Q5: In the infoset, what's the value of the in-scope-namespaces property of the root element of thatDoc? A5: Unspecified; out of scope for this version of the infoset spec. The infoset spec does not cover documents which are not well formed, or documents which are well-formed but don't conform to the Namespaces Rec. It *also* does not cover documents which are well formed and conform to the Namespaces Rec, but which use relative URI references in namespace declarations. Such documents are out of scope, and the infoset spec defines no infoset for them. The XML Core WG is advised to revise the Infoset spec and specify its scope as described. Q6: What does the DOM spec return for the namespaceURI attribute? A6: Unspecified; out of scope for this version of DOM. In the case of a namespace declaration with an absolute URI reference (i.e. a URI reference beginning with a scheme name and a colon), the DOM namespaceURI attribute returns that absolute URI reference. But the namespaceURI attribute in the case of namespace declarations bearing relative URI references is unspecified. The DOM WG is advised to revise the DOM2 spec and specify its scope as described. Q7: what's the value of the XPath namespace-uri() function with <aDoc> as the current node?? A: Unspecified. The 16 November 1999 XPath specification progressed to Recommendation with the understanding that multiple interoperable implementations implemented it as specified, or would soon implement it as specified. As it turns out, we have no evidence that multiple interoperable implementations implement the namespace-uri() function as specified. The XSL (and XLink? Query) WGs are advised to draft a revision of the XPath specification that does not specify the result of the namespace-uri() function in the case of a relative URI reference in a namespace declaration, and request Proposed Recommendation status for the resulting spec. -- **************************************************** * C. M. Sperberg-McQueen * * Research Staff, World Wide Web Consortium * * Route 1, Box 380A, Española NM 87532-9765 * * (that's Espanola with an n-tilde) * * cmsmcq@acm.org, fax: +1 (505) 747-1424 * ****************************************************
Received on Monday, 3 July 2000 21:45:42 UTC