RE: Could XQuery replace the W3C DOM?

There have been a number of responses to my question, so I will answer
them all in this message. 

=============================

Michael Kay wrote:
> As a DOM-replacement, I don't think XQuery offers anything 
> that XSLT doesn't. 

XQuery (with editing extensions) will edit the source document, whereas
XSLT transforms a source document to a (different) destination document.
The current query-only XQuery 1.0 does generate a different document and
hence, yes, it is similar to XSLT. 

If we are using XQuery for user interface programming, say using an XML
document containing an XForms dialog box, I could imagine us using
XQuery editing to change the selection state of a Select1 control
(XForms' radiobutton when rendered to a display). This would be a tiny
change to a (potentially) large document. With XSLT, often (though
agreed, not always) we wish to process the entire document and make
significant changes to it, or to generate a completely different
document (e.g. HTML from XML, or WML from XML). 

=============================

Noah Mendelsohn wrote:
> it's not immediately clear that a query-based implementation 
> would in practice be more rather than less efficient compared to DOM.

If we have an XQuery data engine in the presentation peer, whose
lifetime is the duration of the interactive session, then we can do a
number of things to improve performance over a traditional html/http/DOM
web application. 

As we have a stateful session, we can exploit the fact that the
presentation peer is idle for 99% of the time in a typical user
interface. One simple idea is to pre-load XML documents into the XQuery
data-engine.

> performance is a significant barrier to adoption of XML
> for purposes such as SOAP.

Agreed. However, for processing of general SOAP messages - sequential,
forward-only access to the XML token stream is all most people need, so
SAX/.NET TextReader streaming is the way to go for SOAP. [people should
also go with an efficient SOAP transfer protocol - I reckon (naturally!)
RFC 3288 is best [ http://www.ietf.org/rfc/rfc3288.txt ]). 

For user-interface XML - e.g. an SVG 2D diagram that a user wishes to
edit, then we do need random access to the XML elements - so streaming
XML is of no use. 

To edit such a document, we can either do:
* A traditional application (e.g. Windows EXE)
* Downloadable code (Java applets, .NET assemblies)
* Remote Editing

The four options I can think of to permit Remote Editing of an XML
document are:
* downloaded EcmaScript+DOM (e.g. traditional web application)
* Terminal Services (Citrix)
* a huge SOAP API that in effect is a remotable DOM (the presentation
peer would expose this API and the logic peer would call it) 
* editable XQuery
[aside: anyone got more alternatives to these four?]

For data-entry web forms (e.g. Amazon.com), EcmaScript+DOM is (and will
be) fine. For richer digital content creation apps (e.g. MS Word, Adobe
InDesign, PaintShopPro), EcmaScript+DOM does not provide us with
sufficient functionality to permit remote editing. Terminal services
have not garnered much support. I reckon a SOAP API version of the DOM
will be too slow - so the XQuery approach is best. 

Another important point related to performance is developer know-how.
Assume that in 12 months time senior software engineers will be expected
to know XQuery. Assume we want to build a standard three tier app -
presentation, logic, storage (data). If the API that flows between the
logic peer and the storage peer is based on XQuery, then it is obviously
beneficial if we can also use XQuery as the API between the presentation
peer and the logic peer, and not something totally different.

> we do need to pay more attention to performance as APIs evolve
Definitely agree. 

=============================
 
David Schach wrote:
> ... because the two use different data models. The DOM preserves 
> lexical information that is not available to XQuery.  

For read-only access, the current XQuery Data Model suffices, but when
editing is added to XQuery, the data model will certainly have to
support editing of all aspects of an XML document. 

=============================
Jonathan Robie wrote:

> What would it mean for XQuery to support notification?

We would need some syntax that allows us to identify an element, and say
we wish to be informed whenever it or a child is altered. The use of XML
Events might be of use here. Another option is for an interested peer to
define an XQuery function as a stored procedure, and have it called
whenever the change is detected. 

The various RDBMS guys already support notifications (e.g. see
http://www.microsoft.com/sql/NS/overview.asp ) and we simply need to
functionality in XQuery to provide the data for this. 

One issue with notifications is that they occur asynchronous to the
normal request/response cycle, so a peer-to-peer transfer protocol (e.g.
BEEP) rather than client-server (HTTP) is needed.  
(see http://www.clipcode.com/peer/http_async_notif.htm)

=============================

Adam Bosworth wrote:
> From a performance point of view, one can imagine a factory object
that
> given xml queries, generates optimal code for executing them. That
clearly > could be a lot more efficient than DOM in many many cases.

Agreed. Also, the general concept of XQuery functions that act as stored
procedures in the presentation peer could help. 

Two other advantages are that with a session-based XQuery approach, we
have to send no EcmaScript to the presentation peer (all logic runs on
the logic peer), and what is sent from the logic peer to the
presentation peer are very small XQuery statements - which will very
often fit inside a single TCP packet - with HTML/DOM, when we wish to
edit the current page, we have to resend the entire document or a
significant portion of it.

Aside from performance, the use of XQuery rather than DOM would concur
with the general move away from EcmaScript towards server-side
programming.

Received on Thursday, 29 August 2002 18:33:48 UTC