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

Hello Shane,

Some informal responses from me to your comments.

> -----Original Message-----
> From: Shane McCarron [mailto:shane@aptest.com]
> Sent: 20 November 2007 16:49
> 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.
>
> 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.

I suspect that we have a multplicity of concerns here.

1) wrt to markup language designers updating their language to allow the use of CURIEs in elements/attributes that in earlier versions expect plain URIReferences: They should be warned of the incompatibilities they would induced in doing so.

2) wrt to content authors: Many learn by example. They will see things that look like qnames that may be CURIEs; they will also have been told that CURIEs are a way of writing down URIs and may indeed expect them to work positions where URI references are expected. A number of my local colleagues service a developer list for RDF developers and tell me that that continue to get problems with folks that think they can write, say, dc:title or foaf:mbox in place of a *URIReference* in RDF/XML. When both are present together, document authors do get confused.

Personnally, I would be satisfied with a factual "CANNOT" in place of the imperative "MUST NOT".

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

Hmmm...
        1) "CURIEs are a superset of QNAMEs" (repeatedly claimed in successive drafts)
      2) CURIEs are a way of writing URIs.
        3) #1,#2 => QNAMES are a way of writing URIs.

        4) Given attribute expects URI value => Question: Can URI value be written as CURIE (some of which are QNAMES).

Folks learning by "view source" will sometimes not know whether they are looking at a URI (less likely); a QNAME (probably) or a CURIE.

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

Ok, bearing in mind I too have not discuss your repsonse with the TAG. A warning to language designers does indeed seem appropriate. Re: enforcement wrt to language design, then we probably have to rely on public review and comment, which would be helped by clear warning signs in the relevant CURIE spec.

I've also made a separate, personal comment, that I think there is some obligation to also provide an XMLSchema datatype for CURIEs. I say that on the basis that designers of XML languages should be able to use XML tooling to specify their language. XML datatypes more broadly used that in just XML schema language. Such a data type to include in XML Schema, Relax-NG, RDF property ranges... would provide scope for validation tools to make relevant checks.


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

Thank you.

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

Well, it is the way it is, at least for xmlns. I can see some utility form the pov where a document is machine generated from fragments that may come from independent sources and there is a desire/need to isolate binding that would otherwise have document scope from each other.

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

I cannot promise a useful response to that. I know that there are a variety of dispositions amongst TAG members wrt to whether any venture to provide another mechanism for abbreviating URIs is something to support - other mechanisms being 1)Base plus relative URI; 2) entity decls and references; and there may be a couple more that have been mentioned that don't spring immediately to mind.  Anyway, I'll ask the TAG next time we discuss this topic.

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

BR,

Stuart Williams.
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Tuesday, 27 November 2007 14:00:46 UTC