W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

Re: A rose by any other name is just as thorny...

From: Shane McCarron <shane@aptest.com>
Date: Mon, 29 Mar 2010 09:07:20 -0500
Message-ID: <4BB0B418.3090403@aptest.com>
To: Ivan Herman <ivan@w3.org>
CC: Toby Inkster <tai@g5n.co.uk>, Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>

Ivan Herman wrote:
>> Maybe this was said already - I don't remember.  Can't we just say that references to the XHTML vocabulary are mapped to lower case and any other vocabularies are not?  I know it is sort of a hack, but it would mean that we don't need to to any remote retrieval to know if the vocab is case insensitive or not.
> It is a hack. It is even an ugly hack:-) But if the case insensitiveness of the XHTML case is the _only_ reason why we would use a default @profile for (X)HTML, we could do something like that. (We still have the issue of junk triples, though...)
> But what this should say is that 'if the @vocab value is '....xhtml', then keywords are case insensitive for @rel/@rev. ie, we would not still not list the keywords in the document, the hack would be @vocab value based, so to say, right? 
Yes, I think so.  Well... it is http://www.w3.org/1999/xhtml/vocab# to 
be precise.  We just declare that this is the CURIE 'no prefix mapping' 
at the start of processing, and that any time terms are referenced in 
this vocabulary with no prefix and no colon they are mapped to 
lowercase.  And I don't think I care very much whether this is pretty or 
not.  We have a legacy environment we need to support.  Note that I am 
NOT proposing that they be mapped to lowercase if they are referenced 
with a prefix and a colon (e.g., xv:someTermWithCamelCase).  There are 
mixed case terms in that document now, and I imagine there will be more 
in the future (from aria).

In a more recent email Mark points out that we hard-coded the 'reserved 
words' specifically so that we could avoid this whole problem in RDFa 
1.0.  And I think that was a reasonable solution at the time.  But in 
the brave new world that allows the use of RDFa in HTML5 we need a way 
to ensure that processors adapt as the collection of terms expands.  
Hard-coding these is not a long term solution.  I said above we need to 
support the legacy environment, and I meant it.  But we need to do that 
in a way consistent with our forward, dynamic path for 'terms'.

P.S.  Note my use of the word 'term'.  I am purposely introducing this 
concept every time I write now.  Mostly because it is a word we have not 
used before and I am trying to avoid overloading my position with 
concepts from other positions.  Vocabularies have terms.  In RDFa a 
'term' from the 'default vocabulary' is a CURIE with no prefix and no 
colon - in other words, a CURIE that uses 'no prefix mapping'.  This is 
expressly permitted by the CURIE definition, although in RDFa 1.0 we 
specifically said that the 'no prefix mapping' was undefined.  This left 
the door open to provide for such a mapping in other uses of CURIEs, and 
also in subsequent versions of RDFa.  And here we are, needing such a 
concept.  Nice work, Mark!  In my opinion, as long as the definition of 
what happens in RDFa 1.1 with CURIES that use no prefix mapping is 
consistent with RDFa 1.0's use of 'reserved words', we are laughing.

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Monday, 29 March 2010 14:08:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:46 UTC