[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
> conformant.

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  

   <html xmnls:foo=bar>
    <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 mailing list