- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 29 Aug 2008 00:19:15 +0200
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/>
Received on Thursday, 28 August 2008 15:19:15 UTC