Noah,
The working group resolved to accept the TAG's comments and integrate
them into the draft. I have embedded notes
below as to how that integration was done. You can see an updated
editor's draft via http://www.w3.org/MarkUp/Drafts#curie
Note that the working group has not reviewed this response, but was
instrumental in formulating it. Any errors are entirely my fault. You
should expect a more formal response once the working group has
completed their review.
Thanks again for taking the time to carefully review this
specification. We look forward to a smooth transition to CR in the near
future.
Shane McCarron
[EMAIL PROTECTED] wrote:
* The introduction contains the statement:
<current>
"Unfortunately, QNames are unsuitable in most cases because 1) they are
NOT intended for use in attribute values, and 2) ...".
</current>
Whether or not they were originally intended for such use, QNames are
routinely used in attribute values, e.g. in XML Schema Documents, where
their use is required. We suggest that a better explanation might be
along the lines of:
<proposed>
"Unfortunately, QNames are unsuitable in most cases because 1) the use of
QName as identifiers in attribute values and element content is
problematic as discussed in [2], and 2) ..."
</proposed>
We have used your proposed text. We have also added an informative
reference to the TAG finding.
* The TAG has decided to formally (re)raise a concern that I raised
privately in a note sent in early August [3], and which the TAG itself
raised in an in earlier round of comments [4]. The concern remains that
it is inappropriate to allow for use of new CURIE or safe_CURIE syntax in
languages for which the specifications do not allow for it. Similarly, it
is inappropriate to interpret existing syntax (e.g. pref:xxx) as a CURIE
in cases where the specifications require it be interpreted as a URI.
Accordingly, we suggest that the text that currently reads:
<current>
"In some cases language designers will want to use both URIs and CURIEs as
the value of an attribute. For example, in XHTML+RDFa [XHTMLRDFa] the
about attribute allows a URI to be specified that some metadata is
"about", but it is also be useful to abbreviate this URI, using the
compact syntax. However, the problem is that it is not possible for the
language parser to be completely sure whether it has located a CURIE or a
URI. For example, a resource could be specified as follows:
<p rel="foaf:homePage" about="http://www.example.org/home.html
">home</p>
There is no way to be sure that this is a normal URI, or a CURIE.
Therefore the syntax for carrying a CURIE when there is any possibility of
ambiguity is to enclose the CURIE in square brackets [...]
</current>
Be replaced with:
<proposed>
CURIEs and safe_CURIEs map to IRIs, but neither a CURIE nor a safe_CURIE
<italic>is</italic> an IRI or URI. Accordingly, CURIEs and safe_CURIEs
MUST NOT be used as values for attributes or other content that are
specified to contain only URIs, IRIs, URI-references, IRI-references, etc.
Specifications for particular attribute values or other content MAY be
written to allow either CURIEs or IRIs (or URIs, etc.). The
specifications for such languages MUST provide rules for disambiguantion
in situations where the same string could be interpreted as either a CURIE
or an IRI. One way to do this is to require that all CURIEs be expressed
as safe_CURIEs, implying that all unbracketed strings are to be
interpreted directly as IRIs.
</proposed>
We have integrated your proposed text. Note that at the point in the
document where you suggested we put this, however, safe curie had not
yet been introduced. On balance I decided that this was not a big deal,
and just made the term a forward reference to its production.
* In the introduction, the term "value space" is used in a quite general
manner to refer to a set of values that are grouped together and thus
distinct from similar values in other groups. Later, in the syntax
section, the statement is made: "Note that while the set of IRIs
represents the lexical space of a CURIE, the value space is the set of
URIs (IRIs after canonicalization - see [IRI])." This seems to appeal,
without reference, to notions intended to be either similar in spirit to,
or exactly the same as, the similarly named concepts defined for XML
Schema Datatypes [5,6]. We suggest that, first of all, the inconsistency
in usage between the Introduction and the Syntax section should be
resolved. Secondly, the syntax section should be clearer on whether there
is an assumption that an XML Schema Datatype for CURIE is being defined
(as it is eventually in the Appendix), in which case the terms "lexical
space" and "value space" should probably be made hyperlinks to the XSD
Recommendation. If there is no specific assumption of an XSD Datatype in
the syntax section, then the terms lexical space and value space should
either be dropped from this section, or clarified. We would expect that,
if the terms lexical and value space are retained in this section, the
lexical space would be the set of strings conforming to the BNF for CURIE,
SafeCURIE, etc. If so, those correspondences should be made clear.
Looking ahead to Appendix A, the types you define there are subtypes of
xsd:string. For those types, the correspondence between lexical and value
space is of necessity 1:1 (I.e., as required by the XSD Recommendation),
and thus the value space is also of the form pref:xxxxx. In any case, the
whole story about datatypes, lexical, and value spaces, needs to be
clarified, and needs to be made more consistent with XSD where
appropriate. On balance we suggest you retain the definitions in Appendix
A (with the corrections given below), but replace the word/phrase 'value'
and "value space" in the Introduction with 'name' and "name collection"
respectively.
There was *no* intent that the term "value" in the introduction map to
anything from XSD. It was an unfortunate coincidence. All we were
trying to do was describe collections of scoped data. So basically, we
did what you suggested. We have changed "value" to "name" and made some
other changes as needed so the sentences would scan well. The term
"value" is only used when we are talking about XML "attribute values",
since I personally have no idea how else one might talk about the string
within quotation marks attached to an attribute name in an XML document.
* There is a related, and serious, problem in section 3. The sentence:
<current>
Note that while the set of IRIs represents the lexical space of a CURIE,
the value space is the set of URIs (IRIs after canonicalization - see
[IRI])."
</current>
FWIW this was just an error in the last call draft. We knew what we
meant (lexical space is CURIEs, value space is IRIs) and said it wrong.
It had been corrected already in various intermediate drafts. However,
thanks very much for helping us to tighten this still further.
is wrong on two counts, even after we decouple the terminology from XML
Schema's usage:
1) The 'lexical space' is a subset of strings,
as specified by the BNF at the top of
section 3 (after correction).
2) The 'value space' is strings (intended for use in)
representing IRIs.
So, and given the recommendation below as well, we suggest you replace the
paragraph containing the above sentence with something along the following
lines:
<proposed>
"CURIEs are an abbreviation for strings which are >intended< to represent
IRIs (see [IRI]), but >checking that intent is not part of CURIE
conformance<. The intended IRI is constructed by concatenating the prefix
binding with the reference part, if any. There MUST be a prefix binding
for the prefix (or the default prefix, if the prefix is absent) in scope."
</proposed>
We have integrated this change with some minor word smithing.
Care should be taken to check throughout that the word 'CURIE' is always
used to refer to strings of the form [prefix :] reference. If a name is
needed for the IRI which this maps to, perhaps a phrase such as "expanded
CURIE" should be used, paralleling the term "expanded name" from XML
namespaces; we are unsure as to whether there is, on balance, a need for
such a term.
Since it was never the intent that CURIE mean "expanded CURIE", you are
correct that we don't need such a term. We have done a scan of the
document and are confident that when we say CURIE we mean the lexical
form, not its expansion.
* Section 3 says:
<current>
"A CURIE processor that encounters a value that does not conform the
constraints defined by this specification and by the host language SHOULD
ignore that value. A host language MAY require other behavior."
</current>
This seems to make unwarranted assumptions about the host languages,
whether each such language in fact has a notion of "ignoring" content, and
if so, whether that is in fact the most appropriate error handling
strategy. Accordingly, we recommend instead:
<proposed>
"It is an error if a string required by a host language to be a CURIE or
SafeCURIE fails to satisfy the constraints defined above. Error handling
is implementation-defined." Or, if you prefer, replace that last sentence
with "Rules for error reporting and/or recovery should be provided in the
specification for the host language."
</proposed>
The group agreed to put the onus on host language specifications. Thanks!
The following comments apply to Appendix A, which defines XML Schema
Datatypes relating to CURIEs:
* The status of Appendix A needs to be clarified -- it's currently
described as normative, but at the very least the list of types needs
cross-referencing to the BNF for CURIE and SafeCURIE.
* The syntax in section 3 and the regexps in Appendix A need to be
brought into line. We recommend that this might be done by:
a) Changing the CURIE production to read:
curie := [ prefix ':' ] reference
with a bit of prose saying that the empty
string is _not_ a CURIE.
We have added that prose. Note, however, that the original CURIE
production was correct. It is possible to have a CURIE with no "prefix"
and only a leading colon - such a CURIE uses the host language-defined
default prefix.
b) Changing the core part of the regexps to read:
([\i-[:]][\c-[:]]*:)?.*
As per advice from C. M . Sperberg-McQueen, we have changed the regexps
to read (([\i-[:]][\c-[:]]*)?:)?.+ - we believe this matches the
production. If not, please let us know!
c) Adding a facet to CURIE:
<xs:minLength value="1"/>
d) Adding a facet to SafeCURIE:
<xs:minLength value="3"/>
We have added these facets - thanks!
We trust that our changes will resolve your last call comments.
--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: [EMAIL PROTECTED]
