W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > August 2009

Re: Why bound prefixes are an anti-pattern in language design

From: Danny Ayers <danny.ayers@gmail.com>
Date: Sun, 16 Aug 2009 14:03:27 +0200
Message-ID: <1f2ed5cd0908160503g39ae1aaep322a496d3ef274a1@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Elias Torres <elias@torrez.us>, Martin McEvoy <martin@weborganics.co.uk>, RDFa Developers <public-rdf-in-xhtml-tf@w3.org>, Benjamin Nowack <bnowack@appmosphere.com>
2009/8/16 Ian Hickson <ian@hixie.ch>:

>> In practise I think this means a strict interpretation mechanism is
>> desirable at the statement level, but with ignore-if-fail, so the
>> information communicated by documents (and their embedded data) can be
>> maximally conveyed. I reckon this is generally consistent with the rest
>> of HTML5 design.
>> Thing is, I'm not sure the microdata spec in its current form can
>> support this, while the RDFa approach almost certainly can. Remember
>> looser interpretation should be (and in both cases is) possible further
>> down the chain, depending on the client application.
> I don't see any material difference between RDFa and Microdata that would
> make one or the other more able to support what you describe,

Right, I missed a lot of the URI- (and hence RDF-) friendliness of
Microdata in my initial reading of the spec (set right by your
pointers via twitter, thanks).

other than
> Microdata's self-contained nature (not using prefixes) making Microdata
> somewhat less susceptible to accidental changes in meaning.

I must admit to a bias towards prefixes in general, as in most
circumstances I've seen it's the neatest route to URI-based
extensibility. But, (in particular noting Bengee's remarks about easy
manipulation of quasi-RDF via the DOM), there are clearly other
factors to consider when it comes to HTML.

Similarly, speaking personally, having a sizeable built-in vocabulary
produces a knee-jerk reaction from me - it looks like terribly clunky
design, compared to minimal core + extensions. But I am conflicted on
this point, since it can certainly help in the two typical
circumstances where (<head>less) doc fragments are passed around, copy
& paste and bloglike additions to a doc.

(If HTML5 was starting from scratch I suspect it would have made sense
to have two fairly different sets of conventions, one for complete
docs and another for frags. Atom managed to give a sane story in both
cases - <feed> or <entry> as root - probably only because it was
XML... and it is more likely to be machine-generated from
already-clean sources).


Received on Sunday, 16 August 2009 12:04:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:03 UTC