[whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
hsivonen at iki.fi
Sat Jan 17 15:24:59 PST 2009
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
>>> 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
> 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?
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
> In addition, is that the criteria for pages on the web -- that every
> element in them has to result in different behaviors in browsers,
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
>> 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).
hsivonen at iki.fi
More information about the whatwg