Re: The harm that can come if the W3C supports publication of competing specs

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