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

Hello Shane,

Thank you for your (informal) response which I have shared and discussed with the TAG.

> -----Original Message-----
> From: Shane McCarron [mailto:shane@aptest.com]
> Sent: 12 November 2007 17:25
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: www-html-editor@w3.org
> Subject: Re: TAG Comment on: http://www.w3.org/TR/xhtml-role/#sec_3.1.
>
> Stuart,
>
> I have redirected your comment to our issue tracking system so you
> will receive a formal response from the working group.
>  The XHTML 2 Working Group just had a face to face meeting last week,
> so will not meet to consider your comment for three weeks.
>
> My immediate (informal) response is that CURIEs are currently used in
> mostly new contexts.  If a CURIE is to be used in a context where a
> value could also be a URI, a "safe_curie"
> production is also defined (the CURIE is enclosed in brackets).  See
> the RDFa Syntax document
> (http://www.w3.org/TR/rdfa-syntax) for examples of this, in particular
> on the definitions of @resource and @about.

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."

> 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.

>  Specifically, as an
> example, we do not intend to introduce an updated XHTML M12N
> 1-compatible module where @href takes a URIorCURIE, since markup
> languages based upon M12N 1 are more or less compatible with existing
> user agents and changing the processing requirements of well-known
> attributes would not be a service to our constituents.
>
> 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.

>  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.

> Williams, Stuart (HP Labs, Bristol) wrote:
> > Dear XHTML Editors,
> >
> > Please can you clarify your intentions with respect to the
> use of CURIE's. In particular the TAG would like to understand whether
> the intention is that CURIE's be useable in existing
> elements/attribute where URIReferences are places are already in use,
> or only in new(?) elements and attributes where use of CURIEs is
> specifically called out.
> >
> > The TAG is particularly concerned about how existing
> processors are expected to behave in the presense of markup containing
> CURIEs if they are to be used in places where existing processors
> URIReferences.
> >
> > Many thanks,
> >
> > Stuart Williams
> > on behalf of W3C TAG
> > --
> > Hewlett-Packard Limited registered Office: Cain Road,
> > Bracknell, Berks
> > RG12 1HN Registered No: 690597 England
> >
> >
>
> --
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com

Best regards

Stuart Williams
on behalf of W3C TAG
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

Received on Friday, 16 November 2007 13:57:43 UTC