Reply to: Learning XML/XSL/Xpath/Xquery...

[cykophysh39]

http://www.amazon.co.uk/Beginning-XS...869636&sr=11-1
I found this book invaluable to me to learn the basics of XSLT. I found her writing style really easy to follow,

[WotNxt]

His name is David Pawson!

I have found this site invaluable over the years: http://www.dpawson.co.uk/xsl/index.html

XSL/T is quite tricky to get into if your head is wired for "normal" programming activities but there are some pretty good explanations and real world examples here as well as some more advanced techniques.

Hope this helps.

[AtW]

I don't use ASPX - I have my own simple scripting language with interpreter written in C#, it is very fast and does not depend on IIS - it depends on my own mini webserver written also in C#

[HankWangford]

They call it ASPX I think...

ah the tulipe with '<%' directive actually in the aspx file rather than the code behind class file.
C'mon atw keep the abstraction

You must be one of the Mixed Verbose Code design pattern fans

[AtW]

what mix c# and html........hmmmm

They call it ASPX I think...

[HankWangford]

Problem with extensions is that it breaks the whole point of XSL - abstract yourself from particular language, if you hack with C# in it then you might as well as stick to C#.

Using string functions for simple matching in XmlReader might be faster indeed, but it might be that they use Xpath internally for that anyway - generally speaking I'd say if there are performance constraints on any code that deals with XML/XSL then in this case either custom parsing should be used or XML/XSL should be dropped altogether.

what mix c# and html........hmmmm

[AtW]

Problem with extensions is that it breaks the whole point of XSL - abstract yourself from particular language, if you hack with C# in it then you might as well as stick to C#.

Using string functions for simple matching in XmlReader might be faster indeed, but it might be that they use Xpath internally for that anyway - generally speaking I'd say if there are performance constraints on any code that deals with XML/XSL then in this case either custom parsing should be used or XML/XSL should be dropped altogether.

[Cowboy Bob]

"but even then, if you've already got the whole DOM tree loaded then XPath is a lot more convenient" - that's true but the whole point is to avoid having to do that if poss. (load into an xmldocument). a recent problem was having to extract a repeating series of nodes from a large document which contained many documents and stick them all (the subsets) into oracle. was faster using a reader.

In that case it would be faster using a SAX parser.

[scotspine]

"but even then, if you've already got the whole DOM tree loaded then XPath is a lot more convenient" - that's true but the whole point is to avoid having to do that if poss. (load into an xmldocument). a recent problem was having to extract a repeating series of nodes from a large document which contained many documents and stick them all (the subsets) into oracle. was faster using a reader.

[Cowboy Bob]

i've been told that string functions on an xmlreader is *much* faster than using xpath. be interesting to hear the congregation's take on that...

That's fine if you're just trying to get a particular piece of data out of a DOM tree (but even then, if you've already got the whole DOM tree loaded then XPath is a lot more convenient), but if you're wanting to transform the whole document (say using FOP to convert XML to a PDF) you're not going to want to go down the route of doing it manually.

If you've not got the XML loaded already, the quickest way to find the data is to use a SAX parser and break out when you've found what you need.

[scotspine]

i've been told that string functions on an xmlreader is *much* faster than using xpath. be interesting to hear the congregation's take on that...

[HankWangford]

Xpath and XQuery suck - whoever did them was smoking some bad granola (sp?), the idea was noble but implementation is a missed opportunity - if I was not paid well for implementing a solution using these thingies then I'd probably go postal: they have "variable" keyword to describe a constant because once assigned this "variable" can't be changed, so simple loop with integer accumulator that would count simple sum is out of question, ffs!

The books that I have seen (and I think I checked all of them for this topic) suck badly - the writers talk a lot about obvious things, yet they clearly never worked on a real world problems that would involve language constructs that 99.99999% of programmers are used, the rest 0.0000001% are the ones who smoked bad granola and invented a pile of rubbish that is XSL/XPath/XQuery etc.

Search General archives and around September last year you will find my multiple posts on the subject...

ah but with extension objects you can step away from the limitations of xslt into the managed world and all these problems go away, why iterate a nodeset in xslt when it can be done in c#.

[Cowboy Bob]

Told you

[AtW]

Xpath and XQuery suck - whoever did them was smoking some bad granola (sp?), the idea was noble but implementation is a missed opportunity - if I was not paid well for implementing a solution using these thingies then I'd probably go postal: they have "variable" keyword to describe a constant because once assigned this "variable" can't be changed, so simple loop with integer accumulator that would count simple sum is out of question, ffs!

The books that I have seen (and I think I checked all of them for this topic) suck badly - the writers talk a lot about obvious things, yet they clearly never worked on a real world problems that would involve language constructs that 99.99999% of programmers are used, the rest 0.0000001% are the ones who smoked bad granola and invented a pile of rubbish that is XSL/XPath/XQuery etc.

Search General archives and around September last year you will find my multiple posts on the subject...

[Cowboy Bob]

Ask AtW for help