- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 18 Jan 2009 01:24:59 +0200
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/
Received on Saturday, 17 January 2009 15:24:59 UTC