Re: TAG comments on: http://www.w3.org/TR/2007/WD-curie-20071126/ "CURIE Syntax 1.0"

Part 2, specific comments.

The following contains comments from Shane on how we can reply, updated by  
me with additional remarks.

Steven

------- Forwarded message -------

> More specific comments:
>
> Section 1:
>
>   The implication that CURIEs are simply a reworking of QNames to
>   eliminate some inconvenient restrictions is misleading:
>   the value space of QNames is a space of _pairs_ of URIs and NCNames,
>   whereas the value space of CURIEs is a space of singletons.  So
>   statements such as "values that are valid QNames are a subset of
>   [CURIEs]" and "in other words, the principle used in QNames --- that
>   of combining a namespace name with a local part to generate a URI"
>   should be removed, or at least heavily modified.

We changed the draft to make it clear that it is the lexical space that
is a subset, not that the treatment of QNames is in any way related.

> Section 1.  "1) [QNames] are NOT intended for use in attribute values"
>
>   This is at best misleading -- W3C XML Schema datatypes, of which
>   QName is one, are explicitly and intentionally intended for use to
>   define the allowed content of both attributes and elements.
>
>   Insofar as the TAG has warned about QNames in content (not just
>   attribute values), this has to do with the vulnerability of prefix
>   mappings and CURIEs seem to inherit all of those problems.

CURIEs do inherit the problems of prefix mappings.  The reliance on the
@xmlns mechanism can be brittle.

Not everyone agrees that QNames are explicitly supported as a datatype for
attributes.  Some think they are accidentally supported on an adhoc
basis.  There is no consistent approach to processing such a use.
Moreover, the TAG finding on their use
http://www.w3.org/2001/tag/doc/qnameids.html can lead you to conclude that  
it
would be much better if we used some other type that was NOT overloaded
and that had explicit processing and handling rules so there could be no
ambiguity when CURIEs are used among different contexts.

> Section 3.  Prefixes and even colons are optional (again/still).
>
>   This is just asking for trouble, in my view, particularly the 'no
>   colon' case..  What use cases require default prefixes?  The absence
>   of _any_ visible signal seems very dangerous.

How is it any more dangerous than a relative URI or an unqualified
element name in an XML document? The answer is that we want existing  
expressions (such as rel="index") to (continue to) be valid and meaningful.

> Section 3.  "The concatenation of the prefix value associated with a
>                CURIE and its reference MUST be an IRI [IRI]."
>
>   Just what production is meant here?  I.e. the IRI production itself
>   (I hope so) or the IRI-reference production (I hope not)?

The entire production.  We will make this more explicit.

> Section 3.
>
>   This draft reintroduces the possibility of "additional prefix
>   mapping definition mechanisms".
>
>   We are made uneasy by this for XML-based languages, as it only
>   _increases_ the risk of prefix-bindings being lost. If this
>   provision cannot be removed, at least some justification for it
>   ought to be provided.
>
>   It is particularly worrying that these mechanisms are used in
>   section 4.3 immediately after the statement "documents annotated
>   with RDFa could use the xmlns mechanism to define prefixes". Given
>   that they could, we think at the very least they SHOULD, and would
>   prefer MUST.

This language is non-normative, but has been cleaned up.  Sorry if it
confused or alarmed you.  We appreciate that you consider there to be
some risk associated with losing prefix bindings.  Presumably you mean
when content is copied from a document so that it is taken out of
context.  There is little that can be done about this regardless of the
mechanism used (QNames, CURIEs, QCodes).

The use case for additional prefix mapping mechanisms is there to help
support portability of content among XML and non-XML grammars (e.g.,
XHTML+RDFa and HTML 4.01 + RDFa, should such a profile ever be developed).

> Section 5.  "lexical value"
>
>   This is at best a confusing phrase -- I suggest sticking with
>   "lexical form" instead of "raw CURIE" and "value as IRI" for "lexical
>   value" (or "value as URI", depending on which you actually mean).

We mean "value as IRI".  Good suggestions.

> Section 5.2
>
>   The end of the first paragraph suggests that the following example
>   is about an email address, but that appears not to be the case. At
>   least, it's not clear how to interpret the example:
>
>      <span rel="foaf:homePage" resource="http://...">home</span>
>
>   as an email address.

Thanks. We have corrected this example.

> If this spec. is in fact intended to define an XSD datatype, a schema  
> document, or at least simple type definitions for CURIEs and safe  
> CURIEs, would be a good addition.

Such definitions are included in the current editor's draft.

> [1] http://www.w3.org/MarkUp/2008/ED-curie-20080122/
> [2] http://www.w3.org/TR/2007/WD-curie-20071126/

Received on Wednesday, 23 April 2008 13:09:18 UTC