- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: Mon, 4 Aug 2008 15:16:24 -0600
- To: www-html-editor@w3.org
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>, w3c-xml-cg@w3.org
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 Monday, 4 August 2008 21:17:04 UTC