XML CG comments on XHTML Role Attribute Module last-call draft of 7 April 2008 (PR#8049)

Dear colleagues:

The XML Coordination Group has reviewed the Last-Call draft of "XHTML
Role Attribute Module A module to support role classification of
elements" (http://www.w3.org/TR/2008/WD-xhtml-role-20080407/) and
congratulates the XHTML Working Group on its work.  We realize that
the Last-Call comment period has expired, but we notice that the
document has not yet been republished and we venture to hope these
comments may be useful in any case.

We believe the role attribute module described in this spec is for the
most part described clearly and well.  We have a number of more
specific comments, which are given below.

Comments (1) through (3) below are generic technical comments on areas
where the XML Coordination Group and the Working Groups represented on
it have no special responsibility or authority; they are intended to
call your attention, as one technical colleague to another, to points
you should probably consider in revising the document.  If upon
consideration, you find you disagree with us on them, then we expect
to defer to your judgement (even if we privately disagree).

Comments (4) through (9), on the other hand, relate to areas where the
Working Groups of the XML Activity have particular responsibility and
competence.  If upon consideration you find you disagree with us on
them, then we have a cross-domain coordination issue that requires
attention.

(For the record it should be noted that the XML Coordination Group
reviewed a draft of these comments and gave instructions for
revisions.  The CG has not reviewed the revised form of these comments
and will surely disavow any errors I have introduced during the
revision.)


(1) First, we congratulate the XHTML Working Group for providing a
useful and clear namespace document for the namespace

   http://www.w3.org/1999/xhtml/vocab/

We wish more groups responsible for namespace did so well by the users
of their namespaces.


(2) That said, we think the namespace document could be improved by
the addition of some more information.  A document date would be
helpful, and the identity of those responsible for the text of the
document, and for the namespace, could be stated more explicitly.
(From the fact that "The XHTML specifications are developed by the W3C
XHTML 2 Working Group as part of the W3C HTML Activity", it may be
thought to follow that it is the XHTML 2 Working Group which is
responsible both for the namespace document and for the namespace.
But at least this reader thought it might usefully be clearer; there
are cases where more than one group is involved.)  It might also be
desirable to provide hyperlinks from the namespace document into the
main documentation for the XHTML vocabulary (possibly in multiple
versions).


(3) The namespace document also needs a reference to a namespace
change policy.  At least, that is our reading of the following passage
from the document "URIs for W3C Namespaces" (13 July 1005, rev. 25
April 2006) at http://www.w3.org/2005/07/13-nsuri :

     The TAG finding titled The Disposition of Names in an XML
     Namespace explains how the use of a particular namespace may
     evolve over time. At the W3C, it is important for a group to state
     clearly its expectations for how use of the namespaces it controls
     will or will not change over time. Groups SHOULD document those
     expectations in [or clearly linked from] the Namespace Document.


(4) Our first concern is with the spec's reliance on CURIEs, which are
not as well defined and not as well integrated with other XML
technologies as one might wish.  That is perhaps a comment better
raised against CURIEs themselves than against this specification.  It
suffices here to notice that if the role attribute were defined as a
list of QNames, existing XSD-based technology would provide convenient
access to the namespace names of the individual tokens in the value of
the 'role' attribute; this is not the case with CURIES.

We note that as far as we can tell from the namespace document,
everything currently defined in the XHTML namespace is in fact an
NCName, so that QNames could be used in lieu of CURIES, without loss
of functionality as regards the items in the XHTML namespace -- and,
for software working with standard schema-aware infrastructure, some
substantial gain in functionality.


(5) If it's desired to provide the better validation and easier access
to the namespace binding which would be provided by using the
xsd:QName type, but nevertheless not to rule out the use of CURIEs
which are not QNames, then we suggest the best way to define the role
attribute right now would be to define (1) a union of QName and CURIE
(in that order), and (2) a list of values from that union, and to make
the latter the type of the role attribute.  That would ensure that
XSD-aware software would provide access to the namespace names when
possible, and leave the task to the application only when necessary.


(6) A second concern is that we are unable to locate an XSD definition
of the datatype xh11d:CURIEs.  In general, the documentation for the
namespace <http://www.w3.org/1999/xhtml/datatypes/> falls, we regret
to say, somewhat short of the standard you set with your namespace
document for <http://www.w3.org/1999/xhtml/vocab/>.

Because we have not been able to find the XSD definition, we have not
been able to evaluate the XSD implementation of the role attribute.
What's present in appendix B.1 looks fine as far as it goes, but the
utility of the module really depends on the definition of the datatype
xh11d:CURIEs.

If you can point us to the XSD schema document which contains the
definition of that datatype, we will be happy to review it.


(7) We note that unprefixed names in the value of the 'role' attribute
effectively default to the XHTML namespace.  The first paragraph of
section 3 says in part:

     Any non-qualified value MUST be interpreted as being from the
     XHTML vocabulary at http://www.w3.org/1999/xhtml/vocab#.

We are of mixed mind about this; the longer we have thought about the
matter, the less certain we are that we have understood just what the
sentence is intended to say, and the more likely it seems that it
touches on important fundamental design issues for the use of
namespaces in XML.

On the one hand, this rule seems parallel to the rule in XPath 2.0 and
related specifications that there is a separate default namespace for
function names, which means that a call to count(), for example, need
not be qualified even if a default namespace in the context in which
it occurs.  Since the XML Query and XSL Working Groups provided a
specialized default namespace in this way, it would seem inconsistent
to object to your making a somewhat similar rule for the role
attribute.

On the other hand, the specialized rule for the default function
namespace was forced upon XPath 2.0 by the requirement for
compatibility with XPath 1.0, and might well have been avoided had
compatibility not made it necessary.  Do similar compatibility issues
arise for the role attribute?

The biggest problem is just that the existing xsd:QName datatype, and
datatypes constructed from it in the usual ways, already provide a
rule for deciding how to interpret unprefixed names in a context
where namespace prefixes (e.g. as part of QNames or CURIES) can
appear: they are assigned to the default namespace.  There is no
general-purpose mechanism for changing the default namespace just for
the value of a single attribute.

Either the idiom you seem to be proposing is a good one, and the
definer of an attribute or element or type should be able, as a
general principle, to specify that what namespace bindings should
apply, or at least what the default namespace should be, in values of
that attribute or element or type, or else the idiom is not a good
one, no general mechanism is needed, and you need to be persuaded that
the idiom you seem to be proposing is not a good idea.

For a mixture of technical and aesthetic reasons, we lean toward the
latter view.  The aesthetic reasons are simple: there are already too
many different rules for interpreting unprefixed names (in the
default namespace, for elements and QName values; in no namespace, for
attribute names; in the default function namespace, for function
calls), and adding new ones will not make the world a better place.
The technical reasons are also simple: we see no prospect of being
able to support this kind of mechanism in the generic XML tool stack;
it raises too many issues, and introduces too many incompatibilities
with the existing XML infrastructure.


(8) On yet another hand, we note with a mixture of relief and anxiety
that we were obliged to speak above about "the idiom you seem to be
proposing" -- it's not entirely clear what you are proposing, and so
it's possible that we have misinterpreted it.

Since it is usual for XHTML documents to use
<http://www.w3.org/1999/xhtml> as the default namespace, it will
normally be the case that unprefixed names in the value of the role
attribute are asigned by the usual rules for interpreting namespace
prefixes to the XHTML namespace.  If the remark

     Any non-qualified value MUST be interpreted as being from the
     XHTML vocabulary at http://www.w3.org/1999/xhtml/vocab#.

refers only to this fact, then we suggest only that it be rephrased.

If, on the other hand, it is intended to mean that any token in the
value which has no namespace prefix and no colon is to be assigned to
the XHTML namespace, then we think that this is inconsistent with the
normal rules of namespaces (see point (7) above).


(9) In point (8) we took the sentence

     Any non-qualified value MUST be interpreted as being from the
     XHTML vocabulary at http://www.w3.org/1999/xhtml/vocab#.

to be referring to tokens in the value which lack namespace prefix and
colon.

Strictly speaking, though, the usual terminology for such tokens calls
them "unprefixed", not "unqualified" -- unprefixed names are in fact
namespace-qualified if they are assigned to the default namespace.

So a third interpretation of the sentence is possible, namely that it
is intended to be read as speaking not about unprefixed tokens but
about unqualified tokens, and as saying about them, in effect, that if
the normal rules for resolving namespace prefixes leave a token
unqualified, then (since the namespace rules have NOT assigned the
token to a namespace) an application-specific rule associated with the
role attribute specifies that they should be interpreted as belonging
to the XHTML namespace.

This interpretation relies crucially on the subtle point that
unqualified names are not assigned by the namespace specification to a
magic or default or anonymous namespace, and similarly are NOT said by
the Namespaces Rec to be in no namespace at all (although this
paraphrase is frequently encountered); they are simply not assigned to
a namespace by the Namespace Rec.  There seems no reason that they
could not be assigned to a namespace by an application-level
convention.  But we note that this area is rife with confusion, and we
suggest that if you intend this interpretation, you explain it very
carefully.

No matter which interpretation of this passage you intend, it probably
should be recast to make the meaning clearer.  As indicated above, the
interpretation outlined in comment (7) would cause us grave
misgivings; that in (8) no misgivings at all; that in (9) would give
food for thought.

In any case, we believe that this point in your design requires
careful coordination between the XHTML Working Group and the Working
Groups in the XML Activity, and we invite you to a dialog about the
relevant issues.


--C. M. Sperberg-McQueen
   on behalf of the XML Coordination Group

Received on Wednesday, 24 September 2008 14:05:32 UTC