Hi,
the Elements returned by XQResultItem.getNode() don't appear to support the EventTarget interface:
org.basex.api.dom.BXElem cannot be cast to org.w3c.dom.events.EventTarget
This means we need to serialize the node to an XML string, then parse that string to obtain a org.w3c.dom.Node instance that supports this interface.
This is awkward and highly inefficient.
Why doesn't BaseX support EventTarget (or use the existing DOM implementation provided with Java, which does support DOM events?)
- Godmar
Hi Godmar,
similar to other XQuery processors, BaseX uses its own internal XML representation, which is much more efficient than the classical DOM representation, esp. if several megabytes or gigabytes are to be processed. Next, as most of our users end up using our own APIs, we haven't put more effort into XQJ. Feedback like yours, however, is welcome to see how XQJ is used in practice, and it might give us some ideas how to possibly extend it in future.
As we have limited resources, just as every other open source project, code patches and external contributions are welcome.
Christian
On Sun, Jul 11, 2010 at 10:26 PM, Godmar Back godmar@gmail.com wrote:
Hi, the Elements returned by XQResultItem.getNode() don't appear to support the EventTarget interface: org.basex.api.dom.BXElem cannot be cast to org.w3c.dom.events.EventTarget This means we need to serialize the node to an XML string, then parse that string to obtain a org.w3c.dom.Node instance that supports this interface. This is awkward and highly inefficient. Why doesn't BaseX support EventTarget (or use the existing DOM implementation provided with Java, which does support DOM events?) - Godmar
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
On Sun, Jul 11, 2010 at 4:44 PM, Christian Grün christian.gruen@gmail.comwrote:
Hi Godmar,
similar to other XQuery processors, BaseX uses its own internal XML representation, which is much more efficient than the classical DOM representation, esp. if several megabytes or gigabytes are to be processed. Next, as most of our users end up using our own APIs, we haven't put more effort into XQJ. Feedback like yours, however, is welcome to see how XQJ is used in practice, and it might give us some ideas how to possibly extend it in future.
As we have limited resources, just as every other open source project, code patches and external contributions are welcome.
I understand that iImplementing DOM events takes a fair amount of effort.
Let me describe our use case. We write an AJAX application in which the DOM nodes directly constitute the model (in the MVC sense). UI elements such as text fields etc. are directly mapped to, for instance, attributes of DOM elements. This allows the controller logic to employ DOMMutationEvents. In addition, we use DOMMutationEvents in order to save DOM nodes back to the database (we implement immediate persistence where any change by the user results in an immediate update to the database).
We find this application model very elegant and consistent; needless to say, it requires that DOM events be supported.
I should point out that we also have problems using bindNode() with the org.w3c. Node implementations - it appears that namespaces aren't handled correctly, with 'xmlns=""' appearing in the output when we dump the database after an update. We'll track down this problem and see if it is BaseX related or if we're doing something wrong. But, it's clear that if we could operate on BaseX's DOM implementation, such problems may be reduced.
- Godmar
To briefly follow up on this comment:
On Sun, Jul 11, 2010 at 4:44 PM, Christian Grün christian.gruen@gmail.comwrote:
Next, as most of our users end up using our own APIs, we haven't put more effort into XQJ. Feedback like yours, however, is welcome to see how XQJ is used in practice, and it might give us some ideas how to possibly extend it in future.
So far, we have not allowed any 'import org.basex.*' in our code. I'm not an expert in XML or Java, but it was my understanding that XQJ is the standard way of operating on XML databases from Java code.
Is it not? If not, what should we use without being tied to a particular XML database implementation?
- Godmar
So far, we have not allowed any 'import org.basex.*' in our code. I'm not an expert in XML or Java, but it was my understanding that XQJ is the standard way of operating on XML databases from Java code.
Yes, it's supposed to get the new official Java standard. However, there has been quite some discontent about its usability in the XQuery community; see e.g. here:
http://x-query.com/pipermail/talk/2009-June/
This is why many XML databases and processors don't offer XQJ at all (and XML:DB is out-of-dated)…
http://en.wikipedia.org/wiki/Xml_database
Next, we observe that many users start off with the official APIs and end up using our own API to get the full range of features, and, eventually, make things easier.
After all, I don't want to discourage anyone from using XQJ; some users are completely satisfied with it, and, as an external user, I'd prefer a generic XQuery API as well.
Comments from everyone are welcome. Christian
On Sun, Jul 11, 2010 at 8:04 PM, Christian Grün christian.gruen@gmail.comwrote:
So far, we have not allowed any 'import org.basex.*' in our code. I'm not
an
expert in XML or Java, but it was my understanding that XQJ is the
standard
way of operating on XML databases from Java code.
Yes, it's supposed to get the new official Java standard. However, there has been quite some discontent about its usability in the XQuery community; see e.g. here:
http://x-query.com/pipermail/talk/2009-June/
This is why many XML databases and processors don't offer XQJ at all (and XML:DB is out-of-dated)…
http://en.wikipedia.org/wiki/Xml_database
Next, we observe that many users start off with the official APIs and end up using our own API to get the full range of features, and, eventually, make things easier.
After all, I don't want to discourage anyone from using XQJ; some users are completely satisfied with it, and, as an external user, I'd prefer a generic XQuery API as well.
Comments from everyone are welcome.
Writing code that is BaseX specific (with BaseX a University-supported open source project that has no industrial backing whatsoever) is out of the question. I'm saying this as someone who leads a University-supported open source project myself.
We want to be able to dump our XML content and take it elsewhere should BaseX disappear.
Leaving XQJ aside, are there any other standards, official or not, on the horizon? Alternatively, how people implemented any db-independent layers that could be made to target different XML databases easily?
- Godmar
basex-talk@mailman.uni-konstanz.de