On Thu, 28 Aug 2008 23:55:07 +0200, Ben Adida <[EMAIL PROTECTED]> 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/>

Reply via email to