- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Thu, 27 Oct 2011 12:07:37 +0300
- To: Gregg Kellogg <gregg@kellogg-assoc.com>
- Cc: Ivan Herman <ivan@w3.org>, 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>
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 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/
Received on Thursday, 27 October 2011 09:08:10 UTC