Re: TAG Comment on: http://www.w3.org/TR/xhtml-role/#sec_3.1.

Some comments inline:

Williams, Stuart (HP Labs, Bristol) wrote:
> The TAG remains concerned about the possibility of even 'safe_curies' leaking into attribute values where plain URIReferences are expected. We may be more sanguine about mixing URI and (safe?) CURIEs in new language components (ie. new language extension and wholly new languages).
>
> The TAG requests language to the following effect be included in the normative specification of CURIEs.
>
>         "CURIEs, including safe_curies, MUST NOT be used in attribute or element
>         content where URI content is specified in the relevant language
>         specification."
>
>   

I think you are confused about the target audience of the CURIE spec.
The CURIE spec is targeted at markup language designers who wish to
include this datatype in attributes in their markup languages. This is
not some datatype that a content author can just randomly use in any
attribute and expect it to work.  A CURIE could no more leak into the
value of @dir than a URIReference could.  It would be nonsense.  I mean,
go ahead and use one if you like, but it is not going to be interpreted
as anything except gibberish by a processing agent.


It is up to language designers to decide where in their languages
various datatypes are appropriate.  We believe CURIEs are appropriate
anywhere people envision using QNames in their markup languages today.
Surely you and the TAG are not worried about QNames "leaking" into
places URIReferences are currently used, are you?


>> It is not our intent that a CURIE be used in a context where a
>> URIReference is currently used (e.g., @href) unless we explicitly
>> break backward compatibility.
>>     
>
> We largely concur on this, however we believe that the normative CURIE specification should be explicit and clear on this point, hence the request above.
>   

Obviously I need to discuss your request with the working group.  My
current thinking is that some sort of caveat may be appropriate ("don't
break backward compatibility - its a bad idea and will irritate your
user base!") but that a MUST NOT seems a little strong.  If a language
designer decides to migrate to using URIorCURIE instead of URI in an
attribute, surely that is up to them.  In addition, it seems
unenforceable.  Its not like there is a way to validate that people have
complied with such a restriction.

>> Note that CURIEs are intended to be a superset of QNames, and
>> therefore are suitable for use anywhere a QName is used as an
>> attribute value today.
>>     
>
> Whilst not a TAG comment as such, a point that I and I know at least one other TAG member have made in our own comments is that CURIEs are only a syntactic superset of QNAMEs. What CURIE's and QNAMEs stand for (their value space if you like) are quite different - and I at least think that too should be made explicitly clear otherwise folks risk being misled.
>   

That's a valid and important point.  I will ensure the CURIE spec points
that out very early.  Note that I and others in the XHTML 2 Working
Group believe that the use of QNames in attribute values is an abuse of
the concept - since as you point out the value space is such that it is
unlikely to be what people really are trying to achieve by using QNames
in attribute values.  Usually they are doing that in attribute values as
a way to allow the easy introduction of new scoped, and therefore unique
values.  A CURIE is a token.  Within a document, the token has specific
meaning.  Ideally that meaning can be derived by dereferencing the
expansion of the token (the prefix plus the reference) and interpreting
the resource.

>> We know that in the past the TAG and others have expressed concern
>> about the (mis)use of QNames in attribute values.  We agree that such
>> a use of QNames can be problematic, and hope that by instead using
>> CURIEs in these contexts we can avoid QNames' attendant problems.
>>     
>
> Hmmm... this is a little divergent from the TAG request for clarification that initiated this thread, however seeing as you bring it up, I'll bite.
>
> Much of the TAG's concern about the use of QNAMEs in content stems from the fact that in-scope prefix bindings need to be conveyed to processors in order to correctly interpret a QNAME in context in which it was written. *If* CURIEs are parasitic on namespace declarations (that are scoped to sub-trees) I think that the same attendant problems arise for CURIEs.
>   

This is a subtle issue, and I am happy that you have called it out.  I
personally am very concerned about the reliance on @xmlns:xyz to glean
prefix mappings for CURIEs.  I appreciate the desire of the people who
are in favor of using @xmlns to simplify content authoring.  However, as
you say, it requires that a CURIE be interpreted in context, and that is
not really 1) important, nor 2) terribly easy to do for processors that
may care about CURIE mappings.  The fact that a prefix binding could
*change* within a document stream seems insane to me.  Moreover, since
CURIEs have NOTHING TO DO WITH QNames, and have NOTHING TO DO WITH XML
Namespaces, it seems at best misleading to overload the use of @xmlns in
this way.  Finally, in non-XML languages where there is no @xmlns,
another mechanism is of course required - it would be nice if the
mechanism were consistent across as many languages as possible.  I would
welcome a TAG comment on any of the current working drafts out there
(e.g., rdfa-syntax, xhtml-role, xhtml-access, or curie) with a
recommended mechanism that does not rely upon @xmlns.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Tuesday, 20 November 2007 16:49:35 UTC