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

Re: RDF 1.1 Lite Issue # 2: property vs rel

From: Ivan Herman <ivan@w3.org>
Date: Thu, 27 Oct 2011 14:15:15 +0200
Cc: Gregg Kellogg <gregg@kellogg-assoc.com>, Stéphane Corlosquet <scorlosquet@gmail.com>, Ramanathan V Guha <guha@google.com>, Manu Sporny <msporny@digitalbazaar.com>, HTML Data Task Force WG <public-html-data-tf@w3.org>, RDFa WG <public-rdfa-wg@w3.org>
Message-Id: <BE5F65B4-3393-4878-BAE9-77646483DEF5@w3.org>
To: Henri Sivonen <hsivonen@iki.fi>

On Oct 27, 2011, at 11:07 , Henri Sivonen wrote:

> On Wed, Oct 26, 2011 at 9:25 PM, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:
>> The question is how to determine the host language and RDFa version to use
> 
> I think it's a defect in the design of RDFa that there is such a question.

I do not think there is a defect in the design; RDFa is fairly silent on this issue. FWIW, my processor does, details or optimizations put aside, what you describe below. Except that I am not sure what you mean by:

[[[
If the input is labeled using an XML type, use the implicit but nowhere normatively defined mapping from XML source to a document tree. 
]]]

If the media type is application/xml+xhtml or application/xml+svg, I can use an XML parser (as opposed to a HTML5 parser) to produce a DOM tree on which one can (conceptually) operate, including the element-by-element decision on some specificities bound to the the media type. And yes, if that XML parser fails then the whole process fails.

Ivan


> 
> I think a reasonable (conceptually; feel free to optimize with SAX or
> such) processing model would be:
> 
> 1) Parse input into a document tree. If the input is labeled as
> text/html, use the HTML parsing algorithm. If the input is labeled
> using an XML type, use the implicit but nowhere normatively defined
> mapping from XML source to a document tree. Otherwise, fail.
> 
> 2) Walk the resulting document tree without applying any global "host
> language" modes and without paying attention to the HTMLness flag on
> the document. Feel free to apply host-language-specific rules in a
> local way by examining the namespace of the elements in the tree.
> (That is, if you want to special-case HTML <a href> processing and SVG
> <a xlink:href> processing, that's fine, but choose the behavior on a
> per-element basis instead of per-document basis.) Don't have
> version-dependent behaviors.
> 
> FWIW, the above is how the vast majority of markup processing works in
> browsers. Browsers deviate from what I said above in that they
> sometimes pay attention to the HTMLness flag and to the document
> quirkiness three-value piece of info. (Can you say "three-state
> flag"?) But those cases are there just to deal with legacy
> constraints. It's not something that should be copied to new stuff as
> if checking for the HTMLness flag on the document was role model
> behavior.
> 
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf







Received on Thursday, 27 October 2011 12:13:29 GMT

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