[whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

[Shelley Powers]

Henri Sivonen wrote:
> On Jan 17, 2009, at 21:38, Shelley Powers wrote:
>
>> I'm not doubting the effort that went into getting MathML and SVG 
>> accepted. I've followed the effort associated with SVG since the 
>> beginning.
>>
>> I'm not sure if the same procedure was also applied to the canvas 
>> object, as well as the SQL query capability. Will assume so.
>
> Note that SVG, MathML and SQL have had different popularity 
> trajectories in top four browser engines than RDF.
>
> SVG is going up. At the time it was included in HTML5 (only to be 
> commented out shortly thereafter), three of the top browser engines 
> implemented SVG for retained-mode vector graphics and their SVG 
> support was actively being improved. (One of the top four engines 
> implemented VML, though.)
>
> At the time MathML was included in HTML5, it was supported by Gecko 
> with renewed investment into it as part of the Cairo migration. Also, 
> Opera added some MathML features at that time. Thus, two of the top 
> four engines had active MathML development going on. Further, one of 
> the major MathML implementations is an ActiveX control for IE.
>
> When SQL was included in HTML5, Apple (in WebKit) and Google (in 
> Gears) had decided to use SQLite for this functionality. Even though 
> Firefox doesn't have a Web-exposed database, Firefox also already 
> ships with embedded SQLite. At that point it would have been futile 
> for HTML5 to go against the flow of implementations.
>
> The story of RDF is very different. Of the top four engines, only 
> Gecko has RDF functionality. It was implemented at a time when RDF was 
> a young W3C REC and stuff that were W3C RECs were implemented less 
> critically than nowadays. Unlike SVG and MathML, the RDF code isn't 
> actively developed (see hg logs). Moreover, the general direction 
> seems to be away from using RDF data sources in Firefox internally.
>

Now wait a second, you're changing the parameters of the requirements. 
Before, the criteria was based on the DOM. Now you're saying that the 
browsers actually have to do with something with it.

Who is to say what the browsers will do with RDF in the future?

In addition, is that the criteria for pages on the web -- that every 
element in them has to result in different behaviors in browsers, only? 
What about other user agents?

That seems to me to be looking for RDFa sized holes and them throwing 
them into the criteria, specifically to trip up RDF, and hence, RDFa.


> Meanwhile, the feed example you gave--RSS 1.0--shows how the feed spec 
> community knowingly moved away from RDF with RSS 2.0 and Atom. 
> Furthermore, RSS 1.0 usually isn't parsed into an RDF graph but is 
> treated as XML instead. If RSS 1.0 is evidence, it's evidence 
> *against* RDF.
>
>> The point I'm making is that you set a precedent, and a good one I 
>> think: giving precedence to "not invented here". In other words, to 
>> not re-invent new ways of doing something, but to look for 
>> established processes, models, et al already in place, implemented, 
>> vetted, etc, that solve specific problems. Now that you have accepted 
>> a use case, Martin's, and we've established that RDFa solves the 
>> problem associated with the use case, the issue then becomes is there 
>> another data model already as vetted, documented, implemented that 
>> would better solve the problem.
>
> Clearly, RDFa wasn't properly vetted--as far as the desire to deploy 
> it in text/html goes--when the outcome was that it ended up using 
> markup that doesn't parse into the DOM the same way in HTML and XML.
>
SVG and MathML were both created as XML, and hence were not vetted for 
text/html, either. And yet, here they are. Well, here they'll be, 
eventually.

Come to that -- I don't think the creators of SQL actually ever expected 
that someday SQL  queries would be initiated from HTML pages.

Shelley