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

[Henri Sivonen]

On Jan 17, 2009, at 22:43, Shelley Powers wrote:

> 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.

I'm explaining how SVG, MathML and SQL are different from RDF(a) in a  
way that's very relevant to the practice of including stuff in the spec.

> 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?

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/016045.html 
  is a message where one of the editors of RDFa mentions RDFa together  
with "client-side tools like Ubiquity". That Ubiquity is a Firefox  
extension rather than part of the core feature set is an  
implementation detail. I read this as envisioning browser-sensitivity  
to RDFa.

> 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?

No. However, most of the time, when people publish HTML, they do it to  
elicit browser behavior when a user loads the HTML document in a  
browser.

>> 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.

Actually, the creators of MathML had the good sense and foresight to  
avoid name collisions with HTML even after Namespaces theoretically  
gave them a permission not to care.

Unlike the creators of RDFa, the creators of SVG weren't pushing for  
inclusion in HTML5 or saying that it's OK to serve their XML as text/ 
html--quite the contrary. And the integration would have been nicer if  
the SVG WG had had the same prudence as the Math WG.

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


I don't see the creators of SQL asking for the inclusion of their  
stuff in HTML after building on another spec that is well-known to be  
trouble with HTML (Namespaces in XML in the RDFa case).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/