This document reports the results of an email ballot taken
among members of the W3C XML Plenary Interest Group during the period
3-17 July 2000. The primary purpose of the ballot was to determine whether there is
consensus in the plenary in favor of the proposal outlined below. A
secondary purpose was to document the thinking of the plenary on these
issues, so that WGs who are dealing with these issues can understand
the plenary's rationale.
By a large margin, the XML Plenary endorses the proposal given
below. A number of organizations (both some those who find the
proposal acceptable and some of those voting otherwise) believe that
the W3C should proceed to develop a longer-term solution by means of
the normal WG process.
There are 73 (seventy-three) organizations with representatives in
good standing on any WG of the XML Activity, the XSL WG, or the DOM
WG, and individuals serving as invited experts on one or more of these
WGs. Counting the ballots of these organizations and individuals, the
net result is: Of the votes in the first category, 35 were votes of 'acceptable',
and 12 were votes of 'concur'. Of the abstentions, four were explicit
and the remainder implicit (i.e. no ballot was cast).
In addition, three ballots were cast by organizations or
individuals not recognized by the chairs of the Plenary as being in
good standing on any of the named Working Groups. These ballots did
not affect the net result. [The following message was sent to the XML Plenary mailing list by
the chairs on 3 July 2000.] 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 list suggest
that a proposal originally made by Joe
Kesselman and then elaborated by others
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.
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 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
and another at 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
Q3:But I thought that A3: Even though per RFC 2396 the relative URI reference
Q4:OK, then, what's the namespace name of the root
element in thatDoc? A4:
But be careful with terminology. The 'namespace name' is
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? A7: 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.
On 3 July 2000, the chairs of the XML Plenary sent a ballot
message to the plenary, asking each member organization
represented in the plenary to indicate whether it found the
proposal acceptable or unacceptable. Organizations were also
allowed to abstain, or to instruct that their ballot be counted
with the majority (above, this is termed a vote of concur):
Space for comments was also provided.
Ballots were received from fifty-eight (58) organizations or
individuals. Almost all of these have representatives in good
standing serving on working groups in the XML activity, or the DOM WG,
or the XSL WG, and individuals serving as invited experts on these
working groups; three (not singled out in this tabulation) appear not
to fit this description, but their votes do not affect the result.
It is the recommendation of the XML Plenary that the
proposal described above be adopted, and that new specifications
prepared by W3C Working Groups include statements similar to the
following: This specification does not define an information set [or
whatever] for
XML documents which use relative URIs in namespace declarations. or The scope of this specification includes all well-formed XML
documents which use only absolute URI references in namespace declarations.
Documents which use relative URI references are out of scope, and
not addressed by this specification. or words to similar effect.Results of W3C XML Plenary
Ballot on relative URI References
In namespace declarations
3-17 July 2000
Dave Hollander
C. M. Sperberg-McQueen
6 September 2000
1. Introduction
2. Purpose
3. Conclusions
4. The question
4.1 Chairs' message
Dave Hollander
Co-chairs, W3C XML Plenary IG
4.2
Proposal
http://example.com/pathSeg/thisDoc.xml
:
http://example.org/pathSeg/thatDoc.xml
:
http://www.w3.org/XML/xml-names-19990114-errata
) that the
use of relative URI references in namespace declarations is
deprecated.
../foo
and
http://example.com/foo
meant the same thing in the
context of the base URI
http://example.com/pathSeg/thisDoc.xml
../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.
../foo
, per the namespaces spec as
written.
../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.
4.3 Ballot
5. The data
6. Conclusions