- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sun, 17 Jan 2010 07:46:43 -0500
- To: Boris Zbarsky <bzbarsky@mit.edu>, Graham Klyne <GK@ninebynine.org>, Julian Reschke <julian.reschke@gmx.de>
- Cc: HTMLWG WG <public-html@w3.org>
On Sun, Jan 17, 2010 at 12:11 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > microdata is in CR? See > http://www.w3.org/Consortium/Process/Process-19991111/tr.html#Recs for the > definitions of the REC-track phases. The one where implementation > experience is asked for is CR. > > Now UAs and authors can of course experiment with things that are in earlier > stages, but that's all it is: experimentation. Such experimntation is > useful, obviously, but until you get into CR there are no guarantees of the > spec not radically changing under you. Aren't there lots of features regularly discussed here that can't be changed despite the fact they were never put in a CR? Things like localStorage, or various details of attributes and elements (like the autobuffer discussion recently)? Realistically, the spec stabilizes piece by piece as it gets widely used, and only gets to CR when *everything* is stabilized. In a spec as large as HTML5, that means that some parts will be stable years before the whole spec. It doesn't seem sensible to discourage authors from using new features until unrelated features are stable. In this particular case, I've confirmed with Ian that if Wikipedia starts using microdata, it won't later be changed so as to break our content, so for my purposes it's stable. It could hypothetically be changed by the WG over Ian's objections despite implementations, but that seems unlikely. > In CSS, CR is the stage at which you get to start dropping your vendor > prefixes from your implementation. It's too bad, in some ways, that other > languages don't have a fallback story that allows similar > relatively-painless namespacing of experimental features... CSS vendor prefixes have their own disadvantages, though, right? There's no way to tell them apart from vendor-specific extensions, for one thing. I recently spoke to a web developer who thought border-radius was a nonstandard feature that WebKit and Mozilla happened to agree on. Furthermore, since authors often do "-moz-foo: bar; -webkit-foo: bar; foo: bar", you can't necessarily change the feature so freely anyway. On Sun, Jan 17, 2010 at 4:27 AM, Graham Klyne <GK@ninebynine.org> wrote: > 2. Allow both specs to proceed independently, but *require* both to define a > mapping to the RDF abstract model (and hence semantics). While this would > create more work for implementers (especially of applications or tools that > *consume* embedded data), it would at least prevent the Microdata and RDFa > worlds from coming completely disconnected. (This mapping is clearly a done > deal for RDFa; for Microdata, it doesn't require that browsers and other > Microdata consumers actually implement any RDF processing, just that what > processing they do remains consistent with interpreting data according to > RDF semantics.) This was done very early on: http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html#rdf On Sun, Jan 17, 2010 at 5:14 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > One thing that came up immediately is that a big factor for the complexity > of the additional markup is the choice of the vocabulary. If you can use a > vocabulary optimized for your use case then you won't have to mix terms from > different ones. True. But I would argue that for practical web-authoring purposes, microdata vocabularies will be more useful, because microdata is *meant* for practical web-authoring purposes. Microdata vocabularies, to date, have been designed to answer questions like "How can I tell search engines what licenses my images are under?" RDFa vocabularies (correct me if I'm wrong) seem more likely to answer questions like "How can I expose as much of this page's info as possible to arbitrary machine readers?" Microdata focuses more clearly on practical uses, so its vocabularies *are* better suited to those uses. My ongoing discussion with Manu on wikitech-l has been enlightening to me, and I hope to him as well. My conclusion so far as a web developer is that: 1) I only want to embed metadata in HTML if it's useful to HTML consumers -- web browsers, search engines, and so on. If I don't think HTML consumers will actually use the data, there's no reason to clutter up the HTML markup. I should provide the data in a separate document (thus, neither microdata nor RDFa) to save bandwidth. 2) If I'm providing in-band metadata for practical purposes, microdata is more concise and easier for me to understand than RDFa, and just as expressive for those very limited purposes. Microdata experts also tend to be web developers who share my desire for immediate practical utility, which is helpful. RDFa has more vocabularies available right now, but the microdata vocabularies cover all my use-cases for now, and if they don't, I could probably get a new microdata vocabulary added to the spec pretty easily by proposing my use-case. So microdata is the clear winner to me for in-document markup. I suspect that other web authors will feel similarly, so my current guess is that microdata will wind up with better support than RDFa (for practical web-authoring use-cases) in the long term, which further encourages me to use it. 3) If I'm providing metadata for general-purpose data consumers, inference engines, the sort of thing the web data community rather than the web authoring community does, then I'll provide it separately, probably as RDF if I can figure out how that works. The separate data channel isn't a hassle for me to maintain, since the pages are dynamically generated anyway.
Received on Sunday, 17 January 2010 12:47:17 UTC