- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 4 Dec 2009 15:19:41 -0500
- To: James Graham <jgraham@opera.com>, Maciej Stachowiak <mjs@apple.com>
- Cc: Sam Ruby <rubys@intertwingly.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, public-html <public-html@w3.org>, Ian Hickson <ian@hixie.ch>
On Fri, Dec 4, 2009 at 3:45 AM, James Graham <jgraham@opera.com> wrote: > I should also note that I would be very much against a vote on killing one > of the technologies. That seems as nonsensical as, say, a vote to kill off > either Haskell or Javascript. The two technologies do have a large degree of > overlap in functionality but have fundamentally different design approaches > that may be appropriate for different people in different situations. If one > or the other is indeed so superior that the other need not exist, that > should become clear from usage. It is not something that can reliably be > determined up front by committee. But isn't it more or less the entire point of standards organizations to decide on *one* way of doing things, and make it good? When the W3C decided to form the HTML Working Group, it disbanded the XHTML Working Group (pardon me if my terminology isn't fully correct). Do you think it would have been a better idea to keep both running and see which one the general public favored? With the status quo, anyone who sees serious problems with either microdata or RDFa has reason to try ignoring it and pushing the alternative, rather than fixing the problems in the other spec. For instance, a number of people have criticized RDFa's usability on various grounds. Rather than making a serious effort to improve RDFa's usability, they've pretty much all just supported microdata and hoped RDFa will go away. If microdata were dropped and RDFa integrated into the main spec, then I would expect to see a lot more discussion on how to improve RDFa, and conversely. On the authoring side, uncertainty over the future of metadata embedding will make some authors reluctant to use either RDFa or microdata. I can attest that as a MediaWiki developer, I recommended that MW support neither RDFa nor microdata until the situation became clearer. I don't want us to ship a new version with support for a standard that will die, because it might be painful for us to drop support at a later date. On top of that, of course, you have simple waste of resources. Google paid a presumably significant sum of money to have usability testing done on microdata. Very little money is available for research like this, and it will have been completely wasted if microdata ends up getting abandoned. Likewise, many authors and implementers will end up supporting two different standards instead of one, and/or supporting a standard that ends up dying. The longer both are credible contenders, the more of this waste occurs. As far as establishing a level playing ground goes, there is not and cannot be a level playing ground, because RDFa is much older and better established. It has the huge advantage of inertia. If both specs are presented on an equal footing, then many authors will likely go with RDFa just because they've heard of it or someone else already supports it -- even if microdata is better. The only way to overcome this inertia would be to discontinue work on RDFa and declare microdata the future of metadata embedding in HTML. Then people would gradually switch, as they'll gradually switch from XHTML1 to HTML5. On any given subject, there should be *one* standard, and only one, that is promoted as the recommended way of doing things at any given time. A single standard focuses development effort and makes the platform simpler, and should always be preferred to multiple ways of doing the same thing. This Working Group is in a *much* better position to decide on the relative merits of new technologies than the general web authoring public, and should do so wherever possible to avoid all the problems I've listed. On Fri, Dec 4, 2009 at 12:14 PM, Maciej Stachowiak <mjs@apple.com> wrote: > On Dec 4, 2009, at 6:46 AM, Ian Hickson wrote: >> To return to the point I was making at the top of this e-mail: IMHO, the >> issue boils down to this: >> >> Is it the group's opinion that specification length should be one of >> the working group's primary concerns? >> >> Or is it the group's opinion that the length of the specification >> should be at most a secondary concern? >> >> Could I ask the chairs to consider putting this question to the working >> group? > > The chairs are much more inclined to ask the Working Group to decide on > concrete proposals than high-level abstract questions of principle. Then could we write a change proposal asking that the specification be broken up in a more modular fashion? And an opposing change proposal asking that it be kept the same? As I recall, this sort of high-level description is okay with the chairs' permission. It seems like it would be much more efficient to have a single proposal here. I'm not volunteering to write it, though, since I'm not actually in favor of breaking up the spec.
Received on Friday, 4 December 2009 20:20:39 UTC