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

Thank you for pointing out the informative, normative distinction.  I 
obviously had misread the text I quoted as normative.  I certainly would 
not advocate any MUSTs in non-normative text.  Let me give it some 
thought.  Have you given any consideration to making what you quote as a 
SHOULD a MUST?  It seems to me an outright error to rely on CURIE 
interpretation of a string in a field that's specified as a URI. 

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








Shane McCarron <shane@aptest.com>
Sent by: www-tag-request@w3.org
08/29/2008 12:04 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     www-tag@w3.org
        Subject:        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:35:59 UTC