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

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
--------------------------------------

Received on Friday, 29 August 2008 15:56:18 UTC