W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: FPWD Review Request: HTML+RDFa

From: James Graham <jgraham@opera.com>
Date: Mon, 21 Sep 2009 17:50:20 +0200
Message-ID: <4AB7A0BC.9020301@opera.com>
To: Mark Birbeck <mark.birbeck@webbackplane.com>
CC: Henri Sivonen <hsivonen@iki.fi>, Manu Sporny <msporny@digitalbazaar.com>, HTML WG <public-html@w3.org>, RDFa Developers <public-rdf-in-xhtml-tf@w3.org>
Mark Birbeck wrote:
> Hi James,
> 
> I feel bad pointing this out after all of your hard work...but thanks
> to Elias Torres there has been a Python RDFa parser since early 2006:
> 
>   <http://rdfa.info/2006/06/04/a-python-rdfa-parser/>

I wasn't attempting to prove that it is impossible to implement a 
python-based RDFa parser. That would have been a silly thing to try and 
prove since one could, if it came down to it, implement an entire 
(X|HT)ML parser/tree API with whatever design is needed to process RDFa.

Instead, I was attempting to show that the design of RDFa forces the 
developer to choose to either a) make a careful choice of tree APIs to 
match the assumptions of RDFa (but not of many tree-API implementors who 
are familiar with Namespaces-in-XML 1.0 but not RDFa) or b) treat XML 
and HTML input distinctly.

Given this goal, the existence of a Python based RDFa parser that is 
based on DOM is not that interesting because DOM happens to be one of 
the tree APIs that meets criteria a). Indeed, given the relative quality 
and popularity of common Python DOM implementations compared to other 
tree-model implementations, I would regard a library chosing to use DOM 
today as somewhat suspicious in itself.

> This is because the issue being discussed was not:
> 
>   Can an RDFa parser process xmlns-based attributes when running on
>   top of an XML stack?
> 
> The answer to that is self-evidently 'yes'.

The answer is more like "yes, if you choose an XML stack that allows you 
to hack around the issues caused by using xmlns attributes to declare 
prefixes that are used in content".
Received on Monday, 21 September 2009 15:50:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:08 UTC