Re: [ACTION-4] Re: W3C TAG Response to CURIE Last Call (PR#8055)

Shane:  I don't believe the TAG has formally reviewed the attached 
response from you, but I'm sure I speak for them in thanking you for the 
prompt and careful attention to our concerns.  My own opinion is that the 
dispositions proposed below do indeed completely resolve those concerns, 
but I cannot confirm that formally on behalf of the TAG at this time.  I 
will encourage our chair to schedule a review of your note as soon as 
possible.  Indeed, I am taking the liberty of cross posting this response 
to www-tag@w3.org, which is the TAG's public mailing list, so that other 
members of the community will be aware of your response to our request. 
Thank you again.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Shane McCarron <shane@aptest.com>
10/08/2008 01:18 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     public-xhtml2@w3.org, xhtml2-issues@mn.aptest.com, 
"www-html-editor@w3.org" <www-html-editor@w3.org>
        Subject:        [ACTION-4] Re: W3C TAG Response to CURIE Last Call 
(PR#8055)


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

noah_mendelsohn@us.ibm.com 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: shane@aptest.com

Received on Tuesday, 14 October 2008 19:50:09 UTC