moving toward a decision

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&ntilde;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