Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This note outlines the way in which the XHTML 2 Working Group has addressed comments received during the last call period against the Last Call Working Draft of CURIE Syntax.
During the second last call period for CURIE Syntax the working group received a few comments. This document summarizes those comments and describes the ways in which the comments were addressed by the XHTML 2 Working Group.
Note that the majority of this document is automatically generated from the Working Group's database of comments. As such, it may contain typographical or stylistic errors. If so, these are contained in the original submissions, and the XHTML 2 Working Group elected to not change these submissions.
This document is a Note of the W3C's XHTML 2 Working Group. This Note may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Notes as reference material or to cite them as other than "work in progress". This document is work in progress and does not imply endorsement by the W3C membership.
This document has been produced by the W3C XHTML 2 Working Group as part of the HTML Activity. The goals of the XHTML 2 Working Group are discussed in the XHTML 2 Working Group charter.
This document is governed by the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Please send detailed comments on this document to www-html-editor@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate. Public discussion on HTML features takes place on the mailing list www-html@w3.org.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
| Issue | Working Group Action | Commentor Position | Change Type | Notes |
|---|---|---|---|---|
| 8042: Comment on "CURIE Syntax 1.0" Working Draft 6 May 2008 | Accept | No Response | N/A | The requested changes have been made with the exception of including a RelaxNG definition. The working group is in the process of developing an overall strategy on supporting RelaxNG. When that strategy is ready, we will introduce the appropriate datatypes. |
| 8039: Forms WG Review of "CURIE Syntax 1.0" Working Draft 6 May 2008 | Modify and Accept | Agree | Editorial | We will clear up the wording to help reduce any potential confusion. We will also clarify that host languages are only required to use XMLNS for prefix definition if the language supports XML Namespaces. Thanks! |
| 8051: XML Core WG Comment on CURIEs Last Call | Accept | Disagree | None | We will ensure this position is included in the Disposition of Comments document. |
| 8055: W3C TAG Response to CURIE Last Call | Modify and Accept | Agree | Editorial | All comments accepted and integrated. Detailed response in http://lists.w3.org/Archives/Public/public-xhtml2/2008Oct/0012.html |
| 8040: Comments on http://www.w3.org/TR/2008/WD-curie-20080506/ | Accept | Agree | Editorial | We will implement all of these changes. Thanks! |
| 8037: Comment on example | Accept | Agree | Editorial | We will ensure the examples use the same structure. Thanks! |
| 8052: CURIE review from SWD WG | Modify and Accept | Agree | Editorial | Implemented all suggestions, with minor modifications. |
| 8053: xmlse:foo slightly substantive comment on CURIEs (both in stand alone document, and in RDFa PR) | Modify and Accept | No Response | Editorial | We added a comment to the CURIE specification consistent with the submitters request. We were unable to make changes to the RDFa Syntax specification because of publication requirements. However, since that specification in fact REQUIRES the use of xmlns: to define prefix mappings, in that context the prefix "xmlse" would not be permitted. |
PROBLEM ID: 8042
STATE: Approved and Implemented
EDIT: N/A
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
The requested changes have been made with the exception of including a RelaxNG definition. The working group is in the process of developing an overall strategy on supporting RelaxNG. When that strategy is ready, we will introduce the appropriate datatypes.
ORIGINAL MESSAGE:
Date: Tue, 17 Jun 2008 14:52:46 -0700
From: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
I have previously submitted comments on behalf of the Forms WG.
Below are three personal comments about appendix A.
I apologize for the late date.
These comments all apply to section
http://www.w3.org/TR/2008/WD-curie-20080506/#s_schema titled "XML DTD
and Schema DataTypes."
1. I see no DTD here.
Either the DTD should be supplied or the section title changed.
2. The first paragraph of the section says "This section is normative."
The section then includes some text definitions, followed by an
"informative XML Schema definition" within the normative section.
While this certainly is allowed, it doesn't make much sense
structurally.
Perhaps appendix A could follow the pattern of appendix B and include a
normative A.1, followed by an informative A.2 containing the XML Schema
and an informative A.3 containing the DTD, if it is to be supplied.
3. An informative definition of patterns in RelaxNG Compact Syntax might
enhance readability.
See http://relaxng.org/
Additionally, I understand that RelaxNG modularization is being
considered for XHTML.
Something like this might be appropriate to include as "A.3 Relax NG
Patterns"
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
CURIE = xsd:string { pattern="[\i-[:]][\c-[:]]*:.+" } }
CURIEs = list { CURIE }
SafeCURIE = xsd:string { pattern="\[[\i-[:]][\c-[:]]*:.+\]" }
SafeCURIEs = list { SafeCURIEs }
URIorSafeCURIE = (xsd:anyURI|SafeCURIE)
Since I don't know the details of the import or include structure for
the XHTML RNG modularization under consideration, I can't make a
recommendation, but it is my understanding that Relax NG pattern
definitions are not namespaced, so I did not attempt to define the
namespace http://www.w3.org/1999/xhtml/datatypes/
Thank you for your consideration,
Leigh L. Klotz, Jr.
Xerox Corporation
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> Date: Wed Jun 18 09:42:00 2008 Leigh, Thanks for your comments. The requested changes have been made with the exception of including a RelaxNG definition. The working group is in the process of developing an overall strategy on supporting RelaxNG. When that strategy is ready, we will introduce the appropriate datatypes. We hope this resolves your last call comments on CURIEs. We plan to proceed to Candidate Recommendation as soon as possible.
PROBLEM ID: 8039
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
We will clear up the wording to help reduce any potential confusion. We will also clarify that host languages are only required to use XMLNS for prefix definition if the language supports XML Namespaces. Thanks!
ORIGINAL MESSAGE:
Date: Wed, 11 Jun 2008 07:58:17 -0700 (PDT)
From: "Leigh L Klotz, Jr." <Leigh.Klotz@xerox.com>
The Forms WG has reviewed the CURIE draft
http://www.w3.org/TR/2008/WD-curie-20080506/ and discussed it at our F2F
meeting.
We have the following comments.
* default prefix vs. host language defaults
The document says
host-language defined set of reserved values. Such reserved values
MUST translate into an IRI, just as with any other CURIE. A host
language MAY declare a default prefix value, or MAY provide a
mechanism for defining a default prefix value. In such a host
language, when the prefix is omitted from a CURIE, the default
prefix value MUST be used. Conversely, if such a language does not
define a default prefix value mechanism and does not define a set of
reserved values, CURIEs MUST NOT be used without a leading prefix
and colon.
In XForms, one candidate for use of CURIE is the appearance attribute,
which is presently defined as a union of three enumeration values
(minimal, compact, full) with the the set of qualified-names
containing colons (qname-but-not-ncname).
Given the above quote and with reference to the XHTML uses, it seems
that the course would be to define our enumeration values would be to
define a default prefix as "http://www.w3.org/2002/xforms/vocab#" and
define minimal, compact, and full as "reserved values". We were
initially confused and thought that either of these steps would be
sufficient.
Presumably, as an XML application, XForms has a way to define a
default prefix. So we suggest normative text be added: "An XML
Application SHOULD use namespace prefixes to define CURIE prefixes."
However, not all XML Applcications are namespace-aware so it should
not be required to use namespace prefixes to define CURIE prefixes.
Also we recommend adding normative text to the effect that "XML
Applications MAY define, in prose, a default prefix, which is
different from their default namespace."
It wasn't clear to us that reserved values may be used without
prefixes; other unprefixed values are not allowed.
So perhaps an example XML application that applies the above rules
would be helpful.
* safe_curies
It was not clear that an application would be allowed to specify CURIE
only and not required to include SafeCURIE. This is an important port
for existing applications, because it is not a smooth transition for
XForms from qname-but-not-ncname; that is,
appearance="[minimal]"
is not the same as the currently-specified
appearance="minimal"
Other existing applications may have this same problem.
Therefore, we recommend an informative note that makes clear that
applications can choose to use CURIEs or SafeCURIEs.
Leigh L. Klotz, Jr.
Xerox Corporation
W3C Forms Working Group
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> Date: Tue Jun 17 14:44:10 2008 Leigh, We will clear up the wording to help reduce any potential confusion. We will also clarify that host languages are only required to use XMLNS for prefix definition if the language supports XML Namespaces. Thanks!
PROBLEM ID: 8051
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Accept
USER POSITION: Disagree
NOTES:
We will ensure this position is included in the Disposition of Comments document.
ORIGINAL MESSAGE:
Date: Thu, 21 Aug 2008 16:28:46 -0400 From: "Grosso, Paul" <pgrosso@ptc.com> > -----Original Message----- > From: Roland Merrick [mailto:roland_merrick@uk.ibm.com] > Sent: Thursday, 2008 July 31 11:09 > To: ht@w3.org; PGrosso@ptc.com > Cc: steven.pemberton@cwi.nl; ht@w3.org > Subject: Fw: Last call announcement: CURIEs > > Greetings, it appears that we failed to complete the > requirements of the process for the recent Last of CURIE > Syntax 1.0 by failing to obtain agreement to review the > document and provide feedback by some of the groups we > identified as those we would value review by. > > That said, we are particularly interested in a review by > XML Core Working Group. Various members of the XML Core WG have reviewed the CURIE specification at several stages of development, and the WG has discussed CURIEs among ourselves several times. There is disagreement among the WG members about the value of CURIEs. While some members don't object to them as long as it isn't claimed that a CURIE is a namespace, others fear the similarity with QNames will be confusing at best and possibly problematic for certain applications and tools, and several of us think CURIEs are a bad idea. At this time, while most of the XML Core WG would rather not have CURIEs continue to be proposed and used, we have resigned ourselves to the probability that they will go forward, and we have decided not to make a formal objection. However, we would appreciate that our reluctance be brought to the attention of the W3C staff at the appropriate time in the progression of this specification so that no one can say that the XML Core WG had no problems with the idea of CURIEs. Paul Grosso for the XML Core WG
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> Date: Wed Oct 8 18:28:59 2008 Thanks for conveying the concerns of the core working group. We will ensure that those concerns are included in the transition request when it is put together.
PROBLEM ID: 8055
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
All comments accepted and integrated. Detailed response in http://lists.w3.org/Archives/Public/public-xhtml2/2008Oct/0012.html
ORIGINAL MESSAGE:
From: noah_mendelsohn@us.ibm.com
Date: Sat, 4 Oct 2008 22:19:38 -0400
This note conveys some comments from the TAG's review of your 6 May 2008
working draft titled: "CURIE Syntax 1.0" [1]. First of all, we would
like to make clear that we are overall supportive of the publication of
this work, and we do not anticipate that dealing with any of the following
concerns should greatly slow your progress. We do, however, very much
appreciate your consideration of them.
* 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>
* 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>
* 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 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>
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>
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.
* 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 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.
b) Changing the core part of the regexps to read:
([\i-[:]][\c-[:]]*:)?.*
c) Adding a facet to CURIE:
<xs:minLength value="1"/>
d) Adding a facet to SafeCURIE:
<xs:minLength value="3"/>
Thank you again for your consideration of these comments.
Noah Mendelsohn
for the W3C Technical Architecture Group
[1] http://www.w3.org/TR/2008/WD-curie-20080506/
[2] http://www.w3.org/2001/tag/doc/qnameids.html
[3] http://lists.w3.org/Archives/Public/www-tag/2008Aug/0006.html
[4]
http://lists.w3.org/Archives/Public/www-html-editor/2008JanMar/0014.html
[5] http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/#dt-lexical-space
[6] http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/#dt-value-space
P.S. Tracker, this relates to ACTION-170
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
PROBLEM ID: 8040
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
We will implement all of these changes. Thanks!
ORIGINAL MESSAGE:
From: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com> Date: Tue, 27 May 2008 09:25:19 +0000 Please find below some minor comments on your LC WD < http://www.w3.org/TR/2008/WD-curie-20080506/>. I hope you find them of some use. Regards Stuart Williams (wearing no hats) -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England ================================================================================ Section 1 Introduction: 6th para (Editorial) Please change: "This type is called a "CURIE" or a "Compact URI", and values that are syntactically valid QNames are a subset of this." To: "This type is called a "CURIE" or a "Compact URI". Syntactically, CURIE are a superset of QNames." Rationale: avoid the use of the word 'value' in the original because it is not clear whether it refers to 'surface syntax' expressions or to what such expressions convey. -- Section 1 Introduction: 7th para (boarder-line editorial) "Any language designer considering the use of QNames in attribute values should consider instead using CURIEs, since CURIEs are designed for this purpose, while QNames are not." However, CURIEs in XML attribute values inherit all the problems of QNames in attribute values in terms of a processors access to prefix mappings and the associated scoping issues. In what way are CURIE's designed to be more suitable as attribute values than QNames? ie. are they subject to the same cautions as QNames in content - and if not why not? -- Section 3 Syntax: (boarder-line editorial) The following note is confusing: "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])." I would have taken the lexical space of CURIE to be the QName like syntactic form and the value space to be aligned with that of xsd:anyURI. Being told that the lexical space of CURIE is IRI is confusing (to me at least). -- Section 4.1 SPARQL (Editorial) CURIE allow hierarchical references following the ':' whereas SPARQL is more restrictive. Whilst it is good to show how SPARQL provides for binding a prefix to an IRI, it is potentially misleading to suggest that CURIEs can be used in SPARQL. Were CURIE restricted to just a single segment reference (isegment-nz-nc) rather the more general irelative-ref, the "CURIE-like identifiers" would be a fair expression.
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> Date: Tue Jun 17 15:33:12 2008 Stuart, We will implement all of these changes. Thanks!
PROBLEM ID: 8037
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
We will ensure the examples use the same structure. Thanks!
ORIGINAL MESSAGE:
Date: Thu, 08 May 2008 18:48:58 +0100 From: "Philip TAYLOR (Ret'd)" <P.Taylor@Rhul.Ac.Uk> At > 2.2. Ambiguities Between CURIEs and URIs > > 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, as in the following example: > > <html xmlns:ex="http://www.example.org/"> > <head>...</head> > <body> > <p rel="foaf:homePage" about="[ex:home.html]">home</p> > </body> > </html> the second example fails to explain how the first /should/ have been cast in order to avoid the ambiguity referred to. The two examples should use exactly the same code fragment, modulo the addition of square brackets, in order to clarify the point being made. Philip TAYLOR
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> Date: Tue Jun 17 15:32:51 2008 Philip, We will ensure the examples use the same structure. Thanks!
PROBLEM ID: 8052
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
Implemented all suggestions, with minor modifications.
ORIGINAL MESSAGE:
From: "Jeremy Carroll" <jeremy@topquadrant.com> Date: Mon, 22 Sep 2008 12:45:47 -0700 This is a review of: http://www.w3.org/TR/2008/WD-curie-20080506/ on behalf of the Semantic Web Deployment Working Group. Contents: 1. General 2. Picky Wordsmithing 3. Personal Comment 1. General The Semantic Web Deployment Working Group endorses this Last Call Working Draft, and notes that it is in accordance with the RDFa specification that we have jointly worked on. We believe that more widespread adoption of CURIEs will benefit the Semantic Web community, and that it is of benefit to the Semantic Web community to have this separate specification. 2. Picky Wordsmithing Abstract: OLD: [[ The aim of this document is to outline a syntax for expressing URIs in a generic, abbreviated syntax. While it has been produced in conjunction with the XHTML 2 Working Group, it is not specifically targeted at use by XHTML Family Markup Languages. Note that the target audience for this document is Language designers, not the users of those Languages. ]] SUGGESTED: [[ This document provides a generic, abbreviated syntax for expressing URIs forming an extension to the use of QNames as abbreviations. This syntax is intended to be used as a common element by language designers. Target languages include, but are not limited to, XML languages. The intended audience for this document is Language designers, not the users of those Languages. ]] Section 3: The review was done with section 7 of RDFa alongside. First para: OLD: [[ A CURIE is by definition a syntactic superset of a QName. It is comprised ... ]] SUGGESTED: [[ The following definition makes the set of CURIEs a syntactic superset of the set of QNames, providing a migration path. It is comprised ... ]] OLD: [[ 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]). ]] SUGGESTED (from RDFa section 7): [[ Note that while the lexical space of a CURIE is as defined in *curie* above, the value space is the set of IRIs. ]] OLD: [[ does not conform the constraints ]] SUGGESTED: [[ does not conform to the constraints ]] OLD: [[ Language designers SHOULD only use CURIEs (or safe_curies) as the datatype of new attributes in their markup language, since using them in values where historically an attribute has taken a URI as its datatype could break backward compatibility. ]] SUGGESTED: [[ When revising a language that has historically permitted URIs in certain locations (e.g. as values of a specific attribute), then to ensure backward compatibility, language designers SHOULD NOT permit CURIEs (or safe_curies) as the datatype in the corresponding location, but SHOULD provide a new mechanism (e.g. a new attribute). ]] RATIONALE: The intent is not to restrict using CURIEs to only attribute values, but to prohibit certain ill-advised silent modifications. References: Suggest including authors/editors of the various documents. 3. Personal Comment Our reviewer, Jeremy Carroll from TopQuadrant adds: Within the TopBraid Suite we put great emphasis on having human readable identifiers. We encourage the use of rdfs:label, but use QNames as a fall-back mechanism. As this new CURIE specification rolls out and possibly impacts languages still in development such as N3 and Turtle, this will allow us to improve the readability of the labels produced by our fall-back mechanism. In addition we note that our reviewer made a separate comment: http://lists.w3.org/Archives/Public/www-html-editor/2008JulSep/0023 which we trust is being addressed in the usual way. Jeremy
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> Date: Sat Oct 18 14:59:56 2008 Jeremy and the SWD WG, Thanks for your careful comments. We have integrated most of them into the latest version - our detailed responses are below: > 2. Picky Wordsmithing > > Abstract: > > OLD: > [[ > The aim of this document is to outline a syntax for expressing URIs in a > generic, abbreviated syntax. While it has been produced in conjunction with the > XHTML 2 Working Group, it is not specifically targeted at use by XHTML Family > Markup Languages. Note that the target audience for this document is Language > designers, not the users of those Languages. > ]] > > SUGGESTED: > [[ > This document provides a generic, abbreviated syntax for expressing URIs forming > an extension to the use of QNames as abbreviations. This syntax is intended to > be used as a common element by language designers. Target languages include, but > are not limited to, XML languages. The intended audience for this document is > Language designers, not the users of those Languages. > ]] We have modified your suggested wording, but in general agree that it is better than what we had before! > > Section 3: > > The review was done with section 7 of RDFa alongside. > > First para: > OLD: > [[ > A CURIE is by definition a syntactic superset of a QName. It is comprised ... > ]] > > SUGGESTED: > [[ > The following definition makes the set of CURIEs a syntactic superset of the set > of QNames, > providing a migration path. > > It is comprised ... > ]] We adopted this wording without the mention of migration path - there are many good reasons to use QNames and CURIEs are a poor substitute when QNames are used correctly. > > OLD: > [[ > 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]). > ]] > > SUGGESTED (from RDFa section 7): > [[ > Note that while the lexical space of a CURIE is as defined in *curie* above, the > value space is the set of IRIs. > ]] The TAG suggested wording as well, and it was consistent with yours. We have adopted their wording. > > OLD: > [[ > does not conform the constraints > ]] > > SUGGESTED: > [[ > does not conform to the constraints > ]] Fixed > > OLD: > [[ > Language designers SHOULD only use CURIEs (or safe_curies) as the datatype of > new attributes in their markup language, since using them in values where > historically an attribute has taken a URI as its datatype could break backward > compatibility. > ]] > > SUGGESTED: > [[ > When revising a language that has historically permitted URIs in certain > locations (e.g. as values of a specific attribute), then to ensure backward > compatibility, language designers SHOULD NOT permit CURIEs (or safe_curies) as > the datatype in the corresponding location, but SHOULD provide a new mechanism > (e.g. a new attribute). > ]] Nice - this is what we meant! Thanks again! -Shane
PROBLEM ID: 8053
STATE: Feedback
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
We added a comment to the CURIE specification consistent with the submitters request. We were unable to make changes to the RDFa Syntax specification because of publication requirements. However, since that specification in fact REQUIRES the use of xmlns: to define prefix mappings, in that context the prefix "xmlse" would not be permitted.
ORIGINAL MESSAGE:
From: "Jeremy Carroll" <jeremy@topquadrant.com>
Date: Fri, 12 Sep 2008 09:48:12 -0700
Please remove www-html-editor from the address list if doing a reply-to-all on a WG list.
Apologies that this is a late comment on both specifications.
It arises from work we were doing yesterday.
This is a comment on:
http://www.w3.org/TR/2008/PR-rdfa-syntax-20080904/
and
http://www.w3.org/TR/2008/WD-curie-20080506/
made on behalf of TopQuadrant.
Contents:
Comment
Related Draft Comments
Comment:
***
The string xmlse:foo is (arguably) a CURIE according to the RDFa PR
and is not a CURIE according to the CURIE Last Call WD.
See the text:
[[
prefix values MUST be able to be defined using the 'xmlns:' syntax specified in [XMLNAMES].
]]
in the latter, which is not in the former.
Note both documents have the rule:
[[
prefix := NCName
]]
and NCName is linked to
http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName
which says
[[
Prefixes beginning with the three-letter sequence x, m, l, in any case combination, are reserved for use by XML and XML-related specifications.
]]
but since xml:lang is clearly intended to match the QName construct
http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-QName
it is, in my view, a misreading of Namespaces in XML to have NCName not matching the string "xmlse"
My preferred fix would be:
Delete the offending text from CURIE.
Add the following clarification to both documents:
[[
Note: A CURIE prefix value may case-insensitively begin in the string "xml", but then it is not permitted to be used as a prefix in an xmlns declaration in an XML document.
]]
***
Related Draft Comments:
The background to this observation is further explained in:
http://lists.w3.org/Archives/Public/public-swd-wg/2008Sep/0028
which is in turn a follow up to
http://lists.w3.org/Archives/Public/public-swd-wg/2008Sep/0018
Note msg 0028 took a more positive spin on this observation, but on further reflection this morning led me to this more substantive issue.
Since this comment arose during my review for the SWD WG, there may be further comment from that WG (e.g. either an endorsement or an explicit non-endorsement).
Jeremy
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> Date: Wed Nov 12 17:27:49 2008 Jeremy, Thanks for your comment. The working group discussed this and has the following resolution. Please confirm if this resolution addresses your concern: We added a comment to the CURIE specification consistent with the submitters request. We were unable to make changes to the RDFa Syntax specification because of publication requirements. However, since that specification in fact REQUIRES the use of xmlns: to define prefix mappings, in that context the prefix "xmlse" would not be permitted. > This is a comment on: > http://www.w3.org/TR/2008/PR-rdfa-syntax-20080904/ > and > http://www.w3.org/TR/2008/WD-curie-20080506/ > made on behalf of TopQuadrant. > > Contents: > Comment > Related Draft Comments > > Comment: > *** > The string xmlse:foo is (arguably) a CURIE according to the RDFa PR > and is not a CURIE according to the CURIE Last Call WD. > > See the text: > [[ > prefix values MUST be able to be defined using the 'xmlns:' syntax specified in > [XMLNAMES]. > ]] > in the latter, which is not in the former. > > Note both documents have the rule: > [[ > prefix := NCName > ]] > and NCName is linked to > http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName > > which says > [[ > Prefixes beginning with the three-letter sequence x, m, l, in any case > combination, are reserved for use by XML and XML-related specifications. > ]] > > but since xml:lang is clearly intended to match the QName construct > http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-QName > it is, in my view, a misreading of Namespaces in XML to have NCName not matching > the string "xmlse" > > My preferred fix would be: > Delete the offending text from CURIE. > Add the following clarification to both documents: > [[ > Note: A CURIE prefix value may case-insensitively begin in the string "xml", but > then it is not permitted to be used as a prefix in an xmlns declaration in an > XML document. > ]] > *** > > Related Draft Comments: > > The background to this observation is further explained in: > http://lists.w3.org/Archives/Public/public-swd-wg/2008Sep/0028 > which is in turn a follow up to > http://lists.w3.org/Archives/Public/public-swd-wg/2008Sep/0018 > Note msg 0028 took a more positive spin on this observation, but on further > reflection this morning led me to this more substantive issue. > Since this comment arose during my review for the SWD WG, there may be further > comment from that WG (e.g. either an endorsement or an explicit > non-endorsement). > > Jeremy > > > >