Re: CURIEs: A proposal

Quick note -
  
   One of the objections to microformats is their lack of a namespaces.
RDF/A overcomes this by using "role" and so on attributes, but the
traditional answer being put forward by the hCal and hCard folks is that
they can't use namespaces within a class attribute of a div or span
element precisely because that would break CSS's use of the colon, such
that this <span class="vCard:Country">UK</span> is broken in CSS. So
perhaps if there is to be some "next generation" CURIE that is a
superset of QNames, using some other arbitrary character *besides the
colon* would be a good idea, giving the microformat people "namespaces
for free" as long as they use the "next generation" CURIE and therefore
giving this spec a sort of instant user community.
                                            cheers,
                                                    harry


Williams, Stuart (HP Labs, Bristol) wrote:
> Hello Misha,
>
> FWIW... a colleague suggested the use of '::'  to separate prefix from
> suffix ie. prefix::suffix 
>
> Rationale:
> 1) Visually/Syntactically distinct from QNames.
> 2) Appealingly similar in appearance to QNames.
>
> Regarding 7(a-h) below: 
> This seems to me to leave far too many things open for each language
> using CURIEs to have to specify - making it difficult to conceive of
> generic libraries for handling CURIEs. In particular:
>
> 7a) there should only be one set of syntactic constraints;
> 7b) see '::' suggestion above 
> 7d) *if* CURIEs are genuinely a compact way of writing a URI, there
> should be a *single* mapping from a CURIE to a URI/IRI.
> 7e) should have a single answer... which probably (regrettably) means a
> CURIE is a tuple of {prefix, suffix, prefixURI, compactedURI}
> 7f-g) seems like normal good practice with URIs applies any CURIE spec.
> should remain silent.
> 7h) again surely a matter for generic URI/IRI syntax.
>
> Fixing all of that would leave solely the matter of establish a
> prefix=>URi mapping on a per language basis (7c), and I would hope there
> would be a single approach for XML based languages - other non XML based
> languages (N3 (and friends), SPARQL...) would have to define their own
> mechanisms.
>
> 8b) seems troubling because it risks confusing a Qname with a CURIE.
>
> Just my 2 cents.
>
> Regards
>
> Stuart
> --
>
>
>   
>> -----Original Message-----
>> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
>> On Behalf Of Misha Wolf
>> Sent: 02 June 2006 19:14
>> To: www-tag@w3.org
>> Cc: public-rdf-in-xhtml-tf@w3.org; newsml-2@yahoogroups.com
>> Subject: CURIEs: A proposal
>>
>>
>> Hi folks,
>>
>> A modest proposal, drawing on ideas from Mark, Henry, Tim, 
>> Dan, Norm and others:
>>
>> 1   We agree on a generic syntax and generic rules for Compact URIs 
>>     (CURIEs) in attribute values.
>>
>> 2   We agree that restricted syntaxes and rules will be (or have 
>>     been) defined for specific purposes.   One such purpose is XML 
>>     Namespaces and QNames.
>>
>> 3   Groups within the W3C and elsewhere will define other restricted 
>>     syntaxes and rules for their own purposes.
>>
>> 4   The generic syntax for a CURIE in an attribute value will be:
>>        <foo bar="prefix:suffix"/>
>>
>> 5   The generic syntax for multiple CURIEs in an attribute value 
>>     will (where permitted) be:
>>        <foo bar="prefix1:suffix1 ... prefixN:suffixN"/>
>>
>> 6   Both the prefix and the suffix may (in the generic case) be 
>>     numeric.
>>
>> 7   Each language must specify:
>>
>> 7a  the syntactic constraints (if any) on the prefix and suffix.
>>
>> 7b  how CURIEs and URIs are distinguished, eg through dedicated 
>>     attributes or through a special syntax.
>>
>> 7c  the mechanism for specifying the prefix-to-IRI mapping.  The 
>>     mechanism may use information provided out-of-band.
>>
>> 7d  whether and, if so, how the prefix and suffix are combined to 
>>     form an IRI.
>>
>> 7e  whether the prefix and suffix form a tuple or whether they are 
>>     just a compact representation for an IRI.
>>
>> 7f  whether the IRI mapped to the prefix is required to be 
>>     dereferenceable.
>>
>> 7g  whether the IRI built from the prefix and suffix (and, possibly, 
>>     including also other building blocks) is required to be 
>>     dereferenceable.
>>
>> 7h  whether any fragment identifiers in these IRIs are required to 
>>     be legal XML names.
>>
>> 8   To avoid confusion with XML Namespaces and QNames:
>>
>> 8a  The xmlns attribute is reserved for use with XML Namespaces and 
>>     QNames.
>>
>> 8b  If a prefix matches an xmlns declaration then the CURIE MUST be 
>>     interpreted as a QName.
>>
>> Misha
>> ------------------- NewsML 2 resources ------------------------------
>> http://www.iptc.org         | http://www.iptc.org/std-dev/NAR/1.0
>> http://www.iptc.org/std-dev | http://groups.yahoo.com/group/newsml-2
>>
>>
>> To find out more about Reuters visit www.about.reuters.com
>>
>> Any views expressed in this message are those of the 
>> individual sender, except where the sender specifically 
>> states them to be the views of Reuters Ltd.
>>
>>
>>
>>     
>
>   


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Friday, 9 June 2006 03:49:30 UTC