- From: Ivan Herman <ivan@w3.org>
- Date: Thu, 27 Oct 2011 14:15:15 +0200
- To: Henri Sivonen <hsivonen@iki.fi>
- 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>
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
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 27 October 2011 12:13:29 UTC