385995 - Request to add XQuery

Status: RESOLVED WONTFIX

(Core :: XML, enhancement)

Description

[Brett Zamir]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

XQuery is such an elegant, powerful, and still simple language that was made for handling XML, arguably more powerful than SQL due to its natural way to handle hierarchical data as well as tabular data.

Since Firefox can handle XML (or has come quite a way toward implementing it), having XQuery available to extension developers and thus indirectly if not directly through Firefox to common users, would give a major boost, I feel, for allowing more people to access the data they want and how they want it (and as a side-effect to encourage more people to migrate to XML since they'd have a real  reason to do so).

It'd be useful to allow the power of XQuery both via Javascript and ideally also to common users. One could query the current XML document or maybe even query from several open windows or specified files/URLs and output the results in the same or a new window, etc.

(As a side note, I've been curious to get Berkeley DB XML which has Java and C++ interfaces to allow Firefox to be used to store into collections and xquery documents such as TEI (as well as perhaps use Saxonica or the like to work with visited files (without the extra requirement of adding the viewed page into a XML database) until such time as Firefox could directly support XQuery) to work as XPCOM (using the Java Firefox extension approach which also uses LiveConnect to handle Java objects) and/or through LiveConnect alone or the apparent successor, NPAPI, but this is a bit above my head, and the documentation isn't all too clear to me.)

Maybe the recommended Java API could be used as a model if Javascript or an extension to Javascript could be made to perform xqueries?: http://jcp.org/en/jsr/detail?id=225

If such action were taken, I think it'd be nice to see it work with server-side solutions too like the POW Firefox extension: https://addons.mozilla.org/en-US/firefox/addon/3002

thanks, Brett

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Brett Zamir]

Oh, besides Saxonica (for non-XML database XQuery solutions), Nux, http://dsd.lbl.gov/nux/ , seems pretty mature (or at least ambitious) too.

Comment 2

[Brett Zamir]

My apologies for belaboring this, but I should alter my above comments to suggest that I'd really hope to see XQuery become available, not only for Javascript, but also within the trunk (within the interface). Granted, XQuery requires some study, but, who doesn't need to extract data from a document? (I think XQuery, along with regexp should be taught in schools as well as made part of Firefox--certainly more necessary for most people, I'd say, than even common subjects like trigonometry). The regular Firefox find bar (or search bar) doesn't have any semantic/structural awareness, but given Firefox's original lead in XML support (though now lagging IE in XSL, it seems to me), I'd think it would be ideal to give a general purpose lead in XML queries.

Perhaps a middle-road (but far less powerful) solution could also exist which extracted element names from a document (like the DOM inspector) and allowed one to perform content searches within specific elements, etc., as well as run regular expressions on the current document.

Oh, and besides Saxonica and Nux, XQEngine, http://xqengine.sourceforge.net/ is another open source possibility perhaps.

thanks, Brett

Comment 3

[Cefn Hoile]

Completely agree. 

XQuery has the huge advantage for generating views on data that there is a single syntax for querying and output. This is in contrast to the typical development framework in which two languages (one query language, one imperative language) are used and there's an uneasy binding layer between them.

As a consequence I believe it could be a very good language for technology adopters to be able to get results quickly when wrangling data. 

Taken alongside Firefox's other XML capabilities and the fact that plugins already exist for Firefox to expose XQuery to XUL, this should be fairly doable and have high value.

Comment 4

[Brett Zamir]

One particularly attractive aspect of XQuery would be if a page served in its content type (application/xquery per the 1.0 spec) could be processed over the web, giving a developer-friendly way to make client-side mash-ups--making data sources live and transparent. I would imagine it could be possible to use the Zorba XQuery processor (C++), also being used in XQIB (XQuery In the Browser), to make an XPCOM component?

(XSLT 2.0 would be another standard way to enable such multi-document mash-ups, but besides being uglier imo, currently it seems Saxon is the only implementation and that is in Java or .NET)

Comment 5

[Brett Zamir]

Sedna (available in C and light-weight at only a few MB: http://modis.ispras.ru/sedna/ ) seems to hold promise not only for XQuery in the browser, but also as an XML database in the browser. An XML database can be used for hierarchical queries against documents, as well as against regular relational-style data (perhaps stored in something as simple, and easily editable, as XHTML tables).

Giving extensions and even websites (with permission) access to such a database would among other things, allow them to allow users to continue querying data or hierarchical documents while offline and lighten their own load.

And since XQuery allows its subset, XPath, for queries, and since an adapter for jQuery (or any CSS Selector engine) could most likely be added which comprehensively or near comprehensively converted that syntax to XPath, the very familiar approach of using jQuery could also be made against a local collection of documents (treated perhaps as though they had a common root element). You'd have both flexibility in dealing with hierarchical as well as tabular structures, as well as a very familiar and convenient syntax (with the option to use the less familiar but more powerful XPath and XQuery syntaxes).

If Bug 573886 were also implemented, XQuery/XPath/CSS Selectors in JavaScript could also be applied against any remote resources as well (with user permission), exposing both local resources and the web as a source of data, without requiring server-side scripting, and providing automatic transparency to other developers on how to create their own mash-ups.

I've blogged some other thoughts about this as well (no ads): http://blog.brett-zamir.me/?p=155

Comment 6

[Brett Zamir]

Besides XqUSEme, I've implemented another extension just now, XDIB, which allows an XML database in Firefox, accessible to websites: https://addons.mozilla.org/en-US/firefox/addon/199900/ . It's fairly experimental, but does work with XQueries made against locally stored documents.

Although it seems maybe minds are made up already about IndexedDB, I would hold out some very slight hope that an XML database like Sedna (which is quite small in comparison to other XML dbs) could at least be considered to make it into Firefox, given how good of a fit I think XML/XHTML is with the main staple of the web.

Comment 7

[Henri Sivonen (:hsivonen)]

Considering the bad ratio of development effort and benefit in the case of XSLT in browsers, I think we should WONTFIX this and let people who want XQuery in the browser use JavaScript libraries.

Comment 8

[Brett Zamir]

Per Comment 7, this indeed can be done via XQuery libraries, or, as beautiful of a language as XQuery is, with libraries that emulate XQuery FLWOR expressions through chaining akin to jQuery.