Re: [ISSUE 56] Request TAG guidance on preparing a response to the CURIE last call draft

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