Subject: Re: [xsl] [xslt performance for big xml files] From: Florent Georges <lists@xxxxxxxxxxxx> Date: Sun, 26 Apr 2009 14:51:13 +0000 (GMT) |
Robert Koberg wrote: > Well, the XML DB vendors pitch the XML DB as a web application > platform. There is also the XRX push from some who push this as > well. As soon as you get your first request parameter (or > import your vendor's request namespace) you are into vendor > defined extensions. Thanks for clarification. Yes, you're right. That's because there is room for something that has not been standardized as part of the language (and really, I think that's good, that would have been premature standardization.) Ans that's good that vendors try to fill the gap by providing their users with a way to achieve what they want, even if it is by mean of extensions. In that particular example (get HTTP request params) I think that's good that has not been defined in XQuery itself. I see two (non-exclusive) options: 1/ define a set of extensions to provide those features, as a spec (like a JSR,) hoping vendors will implement it or 2/ create a tool, a framework, implemented for several processors, that provides those features (so you have to maintain it on several processors, and several versions of them.) I think that a lot of people would like to be able to use such an API. If you have any particular ideas about such a framework, please share them on the EXQuery open mailing list available at <http://www.exquery.org/mailing-lists.xml>. > This happens almost right away. It seems to me that the XQuery > standard is a hook for the user that is tossed aside as soon as > they are on the line. Well, XQuery (or XSLT) is not tossed aside as soon as you use any one extension. The developer has to design her code to be easily migrated to another processor (after having evaluated the benefit of using the extension.) But that's still XQuery. > > 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 course, but we are talking about a W3 standard. I can run > HTML on any browser, Funny you take HTML as an example of good interoperability, I would rather use it the other way around ;-) > parse XML with any XML parser, run XSL on any XSL processor > (and there is a mechanism to check for vendor extensions and > choose the correct one based on the processor) Well, I wouldn't say the situation is much different between XSLT and XQuery. Of course, XSLT has use-when. But if you are talking about web applications to be able to be installed on several processors, you can always use a setup process to install the correct vendor-specific library module that encapsulates the vendor-specific extensions. However, it seems to have a demand about such a feature. If you have any idea about that subject, please share them on the EXPath mailing list <http://www.expath.org/lists.html>. There was a thread on the subject last week: http://groups.google.com/group/expath/browse_frm/thread/141ed36fe5733031/0b31 7f5319977f70 > Also, the vendor specific ones are usually better performing > than there standard alternative. Could be, yes. And that could be a legitimate reason to use an extension. But there is no algorithm that will give you a yes/no answer. > > 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. > I am not a DBA, but I use Hibernate to keep the (generated) SQL > vendor agnostic. But again, XQuery is a W3 standard. And SQL an ISO standard. This is difficult to set the scope of a language being specified, as it is actually used outside, and when vendors urge to get a standard. But I think XQuery has a consistent scope, even if maybe an official optional REC or NOTES about an XML-DB admin functions would help interoperability. But that's not the job of XQuery itself I think. > I just can't help feeling there is a con going on. That is > probably too strong, but I hear, "Look at my standards > compliant XML DB - you can use standards based XQuery. However, > to use it as we suggest, you will need to use our extensions." Why not? "If you want to use it behind the XQuery REC, you have to use extensions." Yes, why not? > >> 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?" > I don't understand the point you are making here. The point is: what does mean the first part of you sentence ("the path/to/col contains the documents [...]") ? > > I think EXQuery <http://www.exquery.org/> will play an > > important role in that regard. > Yes and thanks for taking the lead on this. To be honest, Adam has the lead on EXQuery (but we told about EXPath <http://www.expath.org/> stuff also :-p.) PS: Wonder if we shouldn't switch to XQuery Talk or EXQuery...? Regards, -- Florent Georges http://www.fgeorges.org/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [xslt performance for big, Robert Koberg | Thread | Re: [xsl] [xslt performance for big, Robert Koberg |
Re: [xsl] [xslt performance for big, Aditya Sakhuja | Date | RE: [xsl] maintaining sequence numb, Michael Kay |
Month |