- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 16 Jun 2014 12:50:50 -0700
- To: Liam Quin <liam@w3.org>
- Cc: Jirka Kosek <jirka@kosek.cz>, W3C Style <www-style@w3.org>
On Mon, Jun 16, 2014 at 11:59 AM, Liam R E Quin <liam@w3.org> wrote: > [...] > > A couple of possible (relatively minor) misunderstandings here I > think... > > >> Let me be clearer, though: there is no way we'd add XQuery to CSS. > Nor SQL for that matter, nor Python. XQuery is a fully-fledged languaged > used for applications, that sits on top of and extends XPath. > > To be clear here, though, XQuery is not the same as XPath, and I don't > think anyone here is suggesting that XQuery be added to the Web > Platform. > > XPath 1 is already in the browser, and there have in the past been XPath > hooks to CSS, although it would be better to use XPath 3, the current > version, rather than the 1999 XPath 1. > > Better yet for CSS in some ways would be XSLT 3 match patterns, a subset > of XPath designed for streaming. > >> It's a >> redundant query language that browser's are not interested in. Following >> its *model* for something is possible, but I think it's far more useful to >> align with JS APIs, as authors in general are far more likely to be >> familiar with JS stuff. > > A large part of XML's success (and sometimes its failing) is that it > allows document people, who often don't think of themselves as > programmers, to do fairly sophisticated text processing; not everyone > who works with documents wants to be a JavaScript programmer. > > There's some interest from the XML side in documenting XPath (and maybe > XSLT) in the HTML 5 sort of way, and possibly coming up with a subset of > XPath 3 that's close to what browsers already implement (i.e. backwards > compatible but perhaps with some of the additional features that were > found to be needed over the years and that are in XPath 3). But I think > that's a separate conversation. Indeed. ^_^ ~TJ
Received on Monday, 16 June 2014 19:51:38 UTC