On Tuesday, January 8, 2002, at 09:56 PM, Tom Bradford wrote:
On Tuesday, January 8, 2002, at 06:54 PM, Kimbro Staken wrote:
It would produce the same result, because you could use the same namespaced link attributes, but it would require the document to be processed manually instead of automagically, allowing the linking functionality to not be tied specifically to our DOM implementation. A single XQuery query could be used to perform the linking, and it could even be done using SAX or DOM (where right now, we can only do it using DOM).
It may produce the same end result, but it doesn't achieve my goal. Pushing linking into the XQuery layer, to me at least, defeats the whole point of having linking in the first place. I want to be able to use it to simplify and speed up queries, not make them more complex.
For the client/server model, probably not much, but if you were to embed the server into another application (say Tomcat, for example), there may be conflicts as to which DOM is used. Either we can explicitly create our own DOM instances ignoring the DOMBuilder stuff, or we can work cleanly with JAXP, which has the benefit of not requiring inter-implementation conversion, which may slow things down if nodes are imported between DOMs.
If there is runtime cost in converting DOM impls then it seems that would be an optimization point for the developer to worry about as part of the price for embedding the server. Anyway, I'm obviously unclear on the details here, I thought our DOM would always have this problem because of the compression system?
I think you need to explain more what you mean here. I'm not seeing the benefit of pushing it into the XQuery layer or even how it would work.
<above/>
I guess what I really wanted was an example of how linking would be implemented via XQuery.
Closer? Like XQuery updates? :-) I'm not holding my breath.
Oh come on, let's be realistic here. XQuery is far closer to being complete then XUpdate. You know perfectly well that there is an update syntax that exists and has even been implemented a couple times. http://www.lehti.de/beruf/diplomarbeit.pdf Regardless of whether or not it is stable or part of XQuery 1.0 the language is still far more complete. XUpdate it self isn't even complete and the query component required doesn'
t even exist. XSelect is at a far less mature status then the update extensions for XQuery. Additionally XUpdate was never intended to be more then a stop-gap while XQuery was developed. I hate to defend XQuery, but we have to at least keep one foot grounded in reality.
-- Tom Bradford - http://www.tbradford.org Developer - Apache Xindice (Native XML Database) Creator - Project Labrador (XML Object Broker)
Kimbro Staken XML Database Software, Consulting and Writing http://www.xmldatabases.org/
