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

Re: Term case-sensitivity

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Sat, 9 Oct 2010 13:43:26 -0400
To: "nathan@webr3.org" <nathan@webr3.org>
CC: Ivan Herman <ivan@w3.org>, RDFA Working Group <public-rdfa-wg@w3.org>
Message-ID: <D49DD5C2-DFA4-45F8-A261-D5DA903F6BA6@kellogg-assoc.com>
On Oct 9, 2010, at 9:01 AM, Nathan wrote:

Ivan Herman wrote:
There is also another technical issue that can mud the waters. Imagine a

  <div profile="myprofile">
     <div rel="NEXT" resource="asfasdfa"/>

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?

This is defined in XHTML+RDFa as a default vocabulary term, so it has a defined URI (http://www.w3.org/1999/xhtml/vocab#next) and is treated as a term, thus the case-insensitivity issue.

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

Note that it's not @rel and @rev (and @property, for that matter) that are case-insensitive, it's only when the value is processed as a term. If it is a CURIE or URI or even involves a default namespace, it is processed with case-sensitivity. This is actually one way around the issue, instead of creating a term, you can change the default vocabulary, then all suffixes from that vocabulary are treated with case sensitivity, but this only works for suffixes in a single vocabulary, however.

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?

This is a complication that speaks against having special rules for some terms, and probably why they were defined to all be case-insensitive.

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

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

It really makes authoring easier when using multiple namespaces, as should be the case to avoid the tendency to re-name terms from other vocabularies as I pointed out.



Received on Saturday, 9 October 2010 17:44:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:21 UTC