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

Re: ISSUE-24: Proposal for dealing with case-insensitive terms in the XHTML vocabulary

From: Shane McCarron <shane@aptest.com>
Date: Tue, 20 Jul 2010 17:22:49 -0500
Message-ID: <4C4621B9.80701@aptest.com>
To: RDFa WG <public-rdfa-wg@w3.org>
Okay....  Thanks to Manu, I think that I have something new to propose 
that hangs together.  The critical issue that we need to address here is 
how to handle TERMs in a consistent manner.  Special rules for certain 
values of @profile or @vocab are just icky.  Moreover, it is not 
extensible - and extensibility is what RDFa and CURIEs are all about!  
Here's a possible way forward:

    * Change our definition of TERM so that comparing an attribute value
      to the current list of TERMs is *always* done case-insensitively. 
      When an attribute value matches a TERM case-insensitively, the URI
      is the one associated with that TERM.  Note that the URI remains
      case sensitive - no transformation is done on the input nor the
      outpuy beyond our normal mapping of TERM to URI.
    * Have RDFa Core permit host languages to define a default
      collection of TERMs and their mappings.  Define such a collection
      in XHTML+RDFa and HTML+RDFa, and ensure the collection is identical.
    * Require that if a host language defines a default collection, an
      associated RDFa Profile document must contain the definitions of
      the collection, must be at a well known URI, and must not change
      without changing the URI.
    * Permit conforming processors to hard code the declarations from
      the host language-defined profile.
    * Allow, but do not require, that authors indicate the profile in
      use via @profile.
    * Require that attribute values are compared to the current list of
      TERMs before any processing associated with a value of @vocab.

The upshot of this is that rel='FoO' would match a pre-defined TERM of 
'foo', which is what we want.  And the URI associated with the TERM 
'foo' would be used as the predicate for the resulting triple.  There 
are no required server round-trips to determine the list of TERMs, but 
such round trips are permitted if you don't want to hard code the values 
into your processor (you would, however, have to hard code the profile 
URI).  We should probably also commit to never reduce the collection of 
terms - only expand it.

On a related note, we can also permit host languages to define anything 
else that can be present in an RDFa Profile.  This would include, for 
example, prefix mappings.  This is not technically required for what we 
are doing though - and I think as a group we already sort of agreed that 
it would be too difficult to define a collection of popular prefix mappings.

The final related issue that I know of is the 'default prefix' mapping.  
This is the mapping that is used when a CURIE is encountered of the form 
':foo'.  RDFa Syntax and RDFa Core 1.1 both hard code this mapping to 
the XHTML vocabulary (http://www.w3.org/1999/xhtml/vocab#).  We provide 
no mechanism for overriding this definition.  I propose that we leave 
this alone.  The use of ':foo' or ':someTermInXHTMLSpace' might be 
useful in the future.  As an alternative,  we could deprecate this use 
altogether - indicating that in a future version of RDFa that form of 
CURIE may be unresolvable.  That doesn't seem necessary nor friendly to me.

On 7/15/2010 11:08 AM, Shane McCarron wrote:
> We had a good discussion on this issue today - I am sure the minutes 
> will be out shortly.  Unfortunately, this issue dovetails with many 
> other related issues, so it is not completely straightforward to 
> resolve.  Worse yet, I now feel my proposal below was too simplistic - 
> we need to view this in the context of a collection of issues:
>    * case sensitivity of values in rel/rev
>    * Terms enumerated in XHTML+RDFa
>    * Terms defined in w3.org/1999/xhtml/vocab
>    * LinkType values and their registration (IETF, WhatWG, HTML5)
>    * Default vocabulary for Core, XHTML+RDFa, HTML+RDFa
>    * Default profile for XHTML+RDFa and HTML+RDFa
>    * Caching of profiles
>    * Hardcoding of profiles and their evolution
> Consequently, I have withdrawn the proposal below.  I am going to 
> spend some time trying to address all of the above in a single 
> proposal so we can hopefully resolve them all at once.  Obviously, 
> this will be more difficult.  But resolving these issues piecemeal is 
> bound to lead to confusion and an incomplete solution.
> Thanks in advance for your patience.
> On 7/13/2010 5:01 PM, Shane McCarron wrote:
>> In general, I feel that terms should always be treated as case 
>> sensitive.  However, I agree that for backward compatibility reasons, 
>> the terms defined in *OUR* XHTML vocabulary, as extended by terms 
>> that are defined in HTML5, should be mapped to lower case when 
>> processing.
>> I do not think this is an RDFa Core issue.  Rather, I think that in 
>> RDFa Core we should say:
>>    TERMs, CURIEs, and URIs are all case sensitive.  Host Languages may
>>    place further processing requirements on TERMs (e.g., requiring they
>>    be mapped to lower case).
>> In XHTML+RDFa 1.1 we should say:
>>    When referencing TERMs in the vocabulary at
>>    http://www.w3.org/1999/xhtml/vocab, TERMs must be mapped to lower 
>> case.
>> I imagine we would need to say something similar in HTML+RDFa.

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Tuesday, 20 July 2010 22:23:26 UTC

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