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
[email protected]
http://hsivonen.iki.fi/
