Re: [xsl] [xslt performance for big xml files]

Subject: Re: [xsl] [xslt performance for big xml files]
From: Robert Koberg <rob@xxxxxxxxxx>
Date: Sun, 26 Apr 2009 17:52:50 -0400
On Apr 26, 2009, at 10:51 AM, Florent Georges wrote:

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.

In XQuery, yes it is.


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.

No, by definition.




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 ;-)

I disagree. I strongly believe this world wide web thing will eventually takeoff.


Here's the thing:

I can test *the same HTML document* in each modern browser and basically get to what I want. For a browser like IE6, I can still render everything so I can tweak it to conform to the L&F.

I think I became a big XSL fan because I could run transforms in several processor *with the same stylesheet* to see where the minor differences where. (that, and I was getting paid to do it)

Going further, I can drop a standard java webapp in any container. I can drop JSP pages in any container. I can drop velocity templates in any container. I can drop freemarker templates in any container. I can go on and on and on...


The thing about XQuery (as pushed) is you can't do those things. The key is: "as pushed."






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.

Yes, it is different. XSLT is not being pushed as a webapp framework. XQuery is.




 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/0b317f5319977f70

I am confused. I thought I was on this list.




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.

yes. if the standard implementation is there for *basic* spec compliance and the equivalent vendor extension works much better -- it is easy for the day-to-day developer to decide what to use. (but, no algo? I can see at least one)




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.

and very old, relatively speaking


 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 agree. Some slick people are selling the XQuery/XMLDB/XRX solution. Since I work with a few large publishers and the decision makers are being sold things by slicker people than me, I just get a little disturbed.




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?

uff... *vendor lock in*


BTW, I would love to move some of clients away from IE6, but they have these apps that only work on IE6...




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 [...]") ?

really? I presented an example path to collection and described the documents contained within.





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...?

hm. I was one one of these list, I think ?


-Rob



Regards,

--
Florent Georges
http://www.fgeorges.org/

Current Thread