Subject: Re: [xsl] [xslt performance for big xml files] From: Robert Koberg <rob@xxxxxxxxxx> Date: Sun, 26 Apr 2009 06:47:58 -0400 |
Robert Koberg wrote:
I think only considering standard XQuery only is disingenuous, especially the way it is being presented by the vendors and people who write about it.
I am not sure to understand what does mean "the way it is being presented by the vendors and people who write about it."
In my opinion, in every languages I had the opportunity to deal with, you have standard functionalities, and what is implementation- defined. And that's the responsibility of the developer to architecture its code to isolate what is vendor-specific into specific area of its code base.
Whatever the vendor's samples are, how often they use vendor's extensions, that remains the responsibility of the developer to know what is an extension and what is standard, and use wisely this distinction.
Of all the real world applications deployed that use XQuery (I suppose I could be more specific and say as recommended by Liam, but maybe probably not necessary), how many do you think would work on more than one XQuery processor?
I really do not know (how could I know about "all the real world applications deployed using XQuery"?) But even if I could, that would not be an evidence of the intrinsic interoperability of the language, it would only be a clue about how it is used in that regard.
I don't know, but from what I have seen posted on pertinent mailing lists and that XQuery as used/promoted by the XML DBs tend to favor their own extensions in documentation and lists
I agree. I think two different things about that fact: 1/ vendor extensions are required to fulfill areas not covered in standard XQuery, and that's a good thing that vendors provide those features through extensions, as long as they keep themselves within the scope of the standard extensibility mechanisms, and 2/ those extensions are more than often overused in cases where standard XQuery expressions could have been used instead, and when needed, they are not isolated to ease porting the code to another processor.
I guess that's the "database-world syndrome." I've rarely met a DBA who tries to make her SQL code as portable as possible, and who cares about (over)using vendor-specific extensions.
(though there seems to be more caveats on the lists lately, though).
Good ;-) Seriously, I think that's an important point, and I think that during the next couple of year, the way developers write their XQuery expression will determinate if it is important to provide interoperability facilities or instead to try to lock the users: if vendors see that this is a major concern of their users, they will provide it.
Say the path/to/col contains the documents 1.xml, 2.xml and 3.xml cross XQuery processor, what does a collection('path/to/col')/* provide?
Once you will have defined what exactly means "path/to/col contains the documents 1.xml, 2.xml and 3.xml" on several processors, you will get the response.
I think you have to get the problem the other way around: "I have defined my application to use the collection mechanism to organize my documents, how can I setup this processor to get the correct documents when I access this or that collection?"
But I agree there is a set of database-related functions (as administration, inserts, etc.) that would be valuable to everyone to be defined in a standard way, across several XML databases. I think EXQuery <http://www.exquery.org/> will play an important role in that regard.
best, -Rob
Regards,
-- Florent Georges http://www.fgeorges.org/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [xslt performance for big, Florent Georges | Thread | Re: [xsl] [xslt performance for big, Florent Georges |
Re: [xsl] [xslt performance for big, Florent Georges | Date | Re: [xsl] [xslt performance for big, Robert Koberg |
Month |