[whatwg] RDFa statement consistency
Anne van Kesteren
annevk at opera.com
Thu Aug 28 15:19:15 PDT 2008
On Thu, 28 Aug 2008 23:55:07 +0200, Ben Adida <ben at adida.net> wrote:
> Anne van Kesteren wrote:
>> FWIW, when considering language complexity, just considering whether it
>> impacts user agents seems naïve. Eg, it impacts people reading the
>> specification, people writing documentation, people writing books, etc.
> Fair enough.
> Doesn't "SQL in the browser" affect all of those things by at least an
> order of magnitude more? Which SQL spec, given that no SQL engine
> perfectly abides by any of the SQL standards? What kind of transaction
> support and locking?
SQL actually doesn't affect the HTML5 language, but it's a certainly a
complex feature. I don't really think it makes sense to compare that
feature to RDF though... (Because as far as I can tell we're not talking
about adding an RDF triple store to browsers.)
>> Adding attributes is certainly not without cost even if browsers have to
>> do nothing at all.
> The cost is small when we've already written a lot of the documentation
> and specs for how this would work (in XHTML, but it's all DOM-based.)
No, it makes the language more complex. That's a significant cost.
>> (Also, given examples such as Ubiquity, the idea is
>> that it actually does impact user agents in nontrivial ways long term.)
> Ubiquity is a plug-in. The user-agents themselves don't have to support
> those features directly, at least not now.
"not now" was my point, indeed.
> The SQL-in-the-browser spec affects user-agents quite a bit more, since
> they actually *have* to provide SQL capabilities, otherwise they're not
Yes, though again, that's a totally different feature. Supporting
(dynamic) CSS layout probably costs us a lot more, yet having that doesn't
imply we should simply add support for everything that is less complex.
>> The idea and premise of RDF is sort of attractive (people being able to
>> do their own thing, unified data model, etc),
> I'm glad this point is coming across.
>> though I agree with others
>> that the complexity (lengthy URIs, qname/curie cruft) is an issue.
>> Especially given the copy & paste authors you want to enable this for,
>> down the road.
> I'm confused. Copy&Paste is meant to abstract out the complexity for
> simple web publishers.
The point is that the Web author would most likely forget the namespace
<p property=foo:baz> ... </p>
Anyway, I wasn't planning on completely diving into this permathread. Have
Anne van Kesteren
More information about the whatwg