- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Tue, 30 Sep 2008 11:46:25 +0200
- To: "Shane McCarron" <shane@aptest.com>, "XHTML WG" <public-xhtml2@w3.org>
An excellent reply! One slight nit: "The interpretation of a CURIE is always a URI." "A CURIE's lexical space is [ [ prefix ] : ] reference. Its value space is IRI." I think the second one is better. Maybe you should just change URI to IRI in the first sentence, or add "(an IRI actually, which can always be transformed to a URI)". Best wishes, Steven On Wed, 24 Sep 2008 19:22:40 +0200, Shane McCarron <shane@aptest.com> wrote: > (draft response for consideration by the XHTML 2 working group) > > Thanks for your comments. We have discussed these as a working group. > Our comments are scattered below. > > C. M. Sperberg-McQueen wrote: >> >> Dear colleagues: >> >> >> 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. >> >> (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. > Thank you. However, it should be noted that this is not a namespace. > We know that the document mistakenly uses the string "namespace" in a > couple of places, and have fixed that. This is a vocabulary definition > document. It defines a collection of terms that are used in some XHTML > family attributes in conjunction with CURIEs and of course with RDF via > their expanded values (xhv:banner, for example, expands to > http://www.w3.org/1999/xhtml/vocab#banner). The terms in this > vocabulary are never referenced as QNames. More about this later. >> (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). > Thanks for this. We are updating the document to hopefully make this > clearer. For avoidance of doubt, however, note that this document is > THE definition of these terms. Also, as stated above, this is not a > namespace document. It is an XHTML+RDFa document that provides prose > and machine readable definitions for terms defined and used in XHTML > family attribute values. Think "ontology" or "taxonomy" - whichever > word resonates with you to mean "dictionary of terms and their mappings > to fundamental datatypes." >> (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. > We agree that the change policy should be clear. We will include the > policy in the document itself. We believe that the policy is that the > term collection will never get smaller, but may expand as additional > basic terms are defined through the normal evolution of the associated > specifications. >> (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. > The XHTML 2 Working Group is aware that some people in the community > have some concerns about the introduction of CURIEs as a way of > expressing compact URIs. However, the XHTML 2 Working Group remains > convinced that compact URIs are the correct way to represent attribute > values that are to be interpreted as URIs. QNames, while a fine > notation, have some restrictions that our constituents found > unacceptable (e.g., the requirement that the reference portion of the > QName be an NCName). QNames are also only meaningful in the context of > XML languages - some of our constituents want to be able to use XHTML > Role in the context of HTML. CURIEs can be readily supported in HTML. > Finally, and most importantly, QNames do not expand to URIs. They map > into a tuple. The interpretation of a CURIE is always a URI. Since the > point of XHTML Role is to define the "role" of an element in a document, > and those roles are normally defined via RDF, and RDF relationships are > defined using URIs, this direct correspondence between a role value and > its URI is ideal. > > Note that the XHTML 2 Working Group, in conjunction with the Web > Accessibility Initiative and the Semantic Web Deployment Group, are > using CURIEs in several specifications for all the reasons stated > above. Note also that the CURIE specification is a Rec-track document > that has already completed last call and will soon transition to > Candidate Recommendation. > >> (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. > We have an XML Schema definition for the datatype xh11d:CURIE that we > believe addresses this concern. You can see that definition in the > CURIE specification at > http://www.w3.org/MarkUp/2008/ED-curie-20080617/#s_schema (or the latest > version of same). We hope that these data type definitions address your > concern here. Basically the Schema definition is an expansion of the > QName schema definition. >> (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. > Thanks for pointing out that the datatype document is not up to scratch > - we have neglected that for quite some time. I (Shane) have taken an > action to update it. In the interim, please look at the datatype > definitions in XHTML Modularization > (http://www.w3.org/TR/2008/PR-xhtml-modularization-20080611/schema_module_defs.html#a_module_XHTML_Datatypes) > - those are definitive. Or of course at the definition for just the > CURIE datatypes using the reference already provided. >> (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. > I think the fundamental disconnect here is that you are conflating > CURIEs and QNames. And that is surely our fault - the XHTML Role > specification assumes a knowledge of CURIEs and what they are. The > CURIE spec is referenced normatively, of course. But that doesn't mean > most people will have read it nor understood it. We will add some text > to help clarify what a CURIE is. > > However, to respond to your concern: CURIEs are not QNames. While > CURIEs permit the (re)use of xmlns declarations to define prefix > mappings, CURIEs do not in general take advantage of the "XML Namespace" > infrastructure. In particular, CURIEs do not recognize the concept of > the "default" XML Namespace as being any sort of a CURIE mapping at > all. Instead, the CURIE specification indicates that grammars are > permitted to define their rules for default prefix mapping. In XHTML > Family documents, we have declared that unqualified (unprefixed) CURIEs > must be interpreted as being from the XHTML Vocabulary - a basic set of > terms. So to respond to your first point above, the role values do not > default to the XHTML namespace. They default to the XHTML Vocabulary > namespace. > > To get back to your point about the general idiom: The working group > has considered a number of ways to deal with the problem of unprefixed > values. Relying upon the default XML namespace was felt to be > inappropriate for a number of reasons - but mostly for reasons of > content portability (so-called cutting and pasting). We also have a > strong requirement that it be possible to use basic terms without > specifying a prefix - this is associated with ease of use. Our solution > to these two requirements was to resolve that unprefixed CURIEs *can* be > mapped to some pre-defined prefix. In the case of the XHTML family, we > have declared that prefix to be the XHTML Vocabulary URI. >> (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). > Again - CURIEs are not QNames. They must never be interpreted as such. > A CURIE's lexical space is [ [ prefix ] : ] reference. Its value space > is IRI. For purposes of processing, there is no "namespace". If you > are doing lexical space processing, then the CURIE is a token. It won't > mean much, but if you want to look at it as a token go ahead. In order > to do real processing on a CURIE (comparison, dereferencing, whatever) > you need to look at the value space. In the value space, there are no > prefixes. There are IRIs. >> (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. > I don't think you need to read too much into the sentence. I have > changed the wording in the current development draft so that we do not > use the term "qualified" but instead talk about "prefixed" and > "unprefixed". At issue here is the fundamental theory of CURIE > operation. All of your points above seem to want to treat CURIEs as > QNames. CURIEs are not QNames. There are no "normal rules" for > processing such items. There are rules as defined in the CURIE > specification. The issue of the "default" prefix for CURIEs is a > difficult one, and the working group has debated this for many months. > In the context of RDFa, we cheated. I suspect that, in the interest of > reducing confusion, we should cheat here as well. In RDFa Syntax, we > define a collection of "reserved values" for @rel and @rev. We declare > that there is no support for unprefixed CURIEs, and instead define the > datatype for @rel and @rev to be ( Reserved Word | CURIE )+ or something > like that. We further say that when encountering reserved words, they > must be interpreted as being from the XHTML Vocabulary. I do not think > that this addresses the fundamental problem though. That seems to be a > confusion between CURIEs and QNames. Please review your comments in the > context of CURIEs instead of in the context of QNames and see if that > helps to allay your concerns. > >
Received on Tuesday, 30 September 2008 09:47:11 UTC