[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  
indirection:

   <html xmnls:foo=bar>
    ...
    <p property=foo:baz> ... </p>

Anyway, I wasn't planning on completely diving into this permathread. Have  
fun!


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>



More information about the whatwg mailing list