- From: Shane McCarron <shane@aptest.com>
- Date: Fri, 29 Aug 2008 11:04:35 -0500
- To: noah_mendelsohn@us.ibm.com
- CC: www-tag@w3.org
FWIW I have no problem with your proposed text. I would point out, however, that the section you are proposing to modify is informative, not normative. It is just a narrative about how CURIEs are used and examples of when you might need a SafeCURIE because a simple CURIE can be misinterpreted. The NORMATIVE text about this is the final two clauses of section 3: The |safe_curie| production is for use in attribute values where it would be otherwise impossible to disambiguate between a CURIE and a URI. 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. If you feel this wording also needs to be tightened up, please let us know either personally or as part of a formal TAG comment. Thanks! noah_mendelsohn@us.ibm.com wrote: > Shane McCarron writes: > > >> I don't know how to make this any clearer to everyone. If you >> all have suggested wording for the document that would help you >> and future readers grok this more readily, I am completely open >> to it. And I am sure the rest of the working group is as well. >> > > Well, the referenced note at [1] does have proposed text. Please do keep > in mind that [1] represents my personal opinion, not the TAG's, and that I > have held off on submitting it as a formal response to the CURIE draft > pending consideration of the issue by the TAG. That said, my suggestion > on proposed text is out there. For your convenience, I repeat the > pertinent section of [1] here: > > ======BEGIN QUOTE FROM MY NOTE AT [1] ============ > > <fromLastCallDraft> > "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 [...] > </fromLastCallDraft> > > I don't think this is strong enough. It doesn't clealy indicate whether > it is or isn't OK to use CURIES in languages where a URI is currently > required. Also, the phrase "possibility of ambiguity" is sufficiently > vague that it will be hard for designers of specifications that use CURIEs > > to tell if they are conforming. Must [xxx:yyy] syntax be used around all > CURIEs in fields that otherwise accept URIs or IRIs, or only if the > particular CURIE string is syntactically legal as a URI? Thus, I think > the draft should include something along the following lines: > > <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 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 disambiguition 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 as IRIs. > </proposed> > > =================END OF QUOTE ======================= > > Again, the above is at least for the moment, my propsoal and not the > TAG's. Thank you. > > Noah > > [1] http://lists.w3.org/Archives/Public/www-tag/2008Aug/0006.html > > > -------------------------------------- > Noah Mendelsohn > IBM Corporation > One Rogers Street > Cambridge, MA 02142 > 1-617-693-4036 > -------------------------------------- > > > > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
Received on Friday, 29 August 2008 16:05:30 UTC