Re: HTML5 Polyglot spec and RDFa

I think that #3 and #4 essentially boil down to the same thing, as I think it would be odd to specify a host profile that couldn't be represented by a profile document itself. However, I believe that Manu's approach simplifies this by not requiring new profile syntax to be introduced.

#5 Terms are resolved using case-sensitify matching. If no match is found, then a term is resolved using case-insensitive matching.

I agree the intentional miss-spellings of terms is something only found in unit-tests, and we're really trying to protect ourselves from host languages that require case-insensitive matching for terms they define. So, "agent" and "Agent" have clear meanings, "AGENT" is bogus. "NEXT" and "next" are provided due to the legacy requirements of XHV.

If we were to go with #4, then I'd suggest we define a new predicate, such as "rdfa:insensitiveTerm", to indicate the semantics, or allow host languages to define their own mappings, such as "rdfa:roleTerm", or "rdfa:relTerm".

Gregg

On Oct 10, 2010, at 8:32 AM, Toby Inkster wrote:

> On Sun, 10 Oct 2010 10:15:07 +0200
> Ivan Herman <ivan@w3.org> wrote:
> 
>> I am still not 100% sure that the issue raised by Gregg is, in
>> practice, such a show stopper that it would warrant to change the
>> current (clearly simplistic) solution.
> 
> As far as I'm concerned there are four possible paths that we could go
> down which are all quite sensible. (And probably dozens of silly paths
> we could take.)
> 
> 	#1. How RDFa Core 1.1 is currently specified: all terms are
> 	case-insensitive.
> 
> 	#2. All terms are case-sensitive.
> 
> 	#3. Terms are case-sensitive generally, but a host language's
> 	default profile MAY be case-insensitive if the host language's
> 	specification states that it is (and XHTML+RDFa 1.1 would).
> 
> 	#4. Profiles may indicate which terms are case-sensitive and
> 	which are not.
> 
> Currently I've implemented #3 in my parser, though will obviously
> switch to whatever the WG has resolved as RDFa 1.1 approaches stability.
> 
> #3 or #4 are my preferred solutions, because they seem to offer
> profile designers a bit of control while taking into account
> grandfathered case-insensitive terms. 
> 
> -- 
> Toby A Inkster
> <mailto:mail@tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
>

Received on Sunday, 10 October 2010 20:07:05 UTC