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

Re: Term case-sensitivity

From: Nathan <nathan@webr3.org>
Date: Sat, 09 Oct 2010 17:01:32 +0100
Message-ID: <4CB091DC.5080005@webr3.org>
To: Ivan Herman <ivan@w3.org>
CC: Gregg Kellogg <gregg@kellogg-assoc.com>, RDFA Working Group <public-rdfa-wg@w3.org>
Ivan Herman wrote:
> There is also another technical issue that can mud the waters. Imagine a
> 
> <body>
>    <div profile="myprofile">
>       <div rel="NEXT" resource="asfasdfa"/>
>    </div>
> </body>
> 
> and, say, myprofile defines a term for 'next' with
> 
> [ 
>    a rdfa:CaseSensitiveMapping ;
>    rdfa:term "next" ; 
>    rdfa:onUri "blabla" 
> ]
> 
> It is not absolutely clear in my mind what would be the property generated for @rel. If there was no profile, NEXT==next, it is the relevant XHTML URI for 'next'. But the profile gives another meaning to 'next' but makes it in a case sensitive way. Would NEXT be mapped against the XHTML URI? Probably yes, but I think it is a bit disturbing for users if these things are messed up, don't you think?

What triple would be produced for a @rel of 'next' (the link relation), 
do we have a URI this resolves to?

Assuming the case-insensitivity rules of rel and rev don't affect CURIEs 
since they resolve to URIs before comparison? (important to clarify this 
imo)

Precedence rules for processing? If the token doesn't match a registered 
Link Relation in a case insensitive fashion, then check rdfa:terms in a 
case-sensitive fashion?

Appears to me like we can't redefine @rel and @rev to be case sensitive, 
and we can't define that a plain literal is to be compared in a 
case-insensitive fashion, and that we'd be unwise to let the link 
relation of 'next' produce anything other than the expected webscale 
results.

How badly do we need rdfa:term? (assuming quite badly with microformat 
considerations)

TIA,

Nathan
Received on Saturday, 9 October 2010 16:02:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:08 GMT