W3C home > Mailing lists > Public > public-html-data-tf@w3.org > October 2011

Re: htmldata-ISSUE-2 (Use of rdf:XMLLiteral): Should Microdata-RDF generate XMLLiteral values [Microdata to RDF]

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Mon, 24 Oct 2011 09:28:32 -0400
To: Philip Jägenstedt <philipj@opera.com>
CC: "public-html-data-tf@w3.org" <public-html-data-tf@w3.org>
Message-ID: <5B9F8B69-A99B-4410-86FC-75CD9299A96B@kellogg-assoc.com>
On Oct 24, 2011, at 2:11 AM, "Philip Jägenstedt" <philipj@opera.com> wrote:

> On Fri, 21 Oct 2011 19:51:56 +0200, Gregg Kellogg  
> <gregg@kellogg-assoc.com> wrote:
> 
>> On Oct 21, 2011, at 1:55 AM, Philip Jägenstedt wrote:
>> 
>>> On Thu, 20 Oct 2011 20:42:32 +0200, HTML Data Task Force Issue Tracker
>>> <sysbot+tracker@w3.org> wrote:
>>> 
>>>> Should the Microdata to RDF spec parallel RDFa and generate an
>>>> rdf:XMLLiteral in this case?
>>> 
>>> I'd say no. XML is not part of the microdata model, and it would be very
>>> bad indeed if some toolchains saw this as plain text while others saw it
>>> as a DOM fragment.
>> 
>> Regarding different interpretations by tool chains, given that we seem  
>> to be going to a parameterized transformation algorithm, this would be  
>> only one area where different tools might generate different results.  
>> I'd rather see us come up with unambiguous transformation rules that did  
>> not rely on the state of different provided to a parser, but that might  
>> need to be left to another group that would take on this work at the end  
>> of the TF.
> 
> I don't understand, what is a "parameterized transformation algorithm" and  
> in what other areas do we expect incompatible implementation of microdata?  
> Surely we expect that the spec(s) will leave no room for interpretation or  
> incompatibility, such that all implementations will do exactly the same  
> thing?

Jeni has said that this group should provide options for performing an RDF transformation that another WG might resolve. This _could_ include vocabulary-specific rules and runtime parameters with default behavior.

As I've said, my preference would be no vocabulary-specific or parameter differences, but writing it this way, at least for now, provides a way of talking about and maybe testing those behaviors.

Personally, I'd like to resolve the URI generation rules in favor of the flat-namespace algorithm in my current ED. I don't particularly care for having different processing rules for different vocabularies.

Gregg

> -- 
> Philip Jägenstedt
> Core Developer
> Opera Software
> 
Received on Monday, 24 October 2011 13:29:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 24 October 2011 13:29:23 GMT