Xsl

[AtW]

ok, I am wrong - you right. But I had a few very frustrating days and I wanted to whine and moan about it, okay?

 

[Joe Black]

I think AtW is suffering from the "if the only tool you know is a hammer, everything looks like a nail" syndrome.

A good metaphor BM.

Lot's of things can be done in XSLT, running totals etc, if you just think of them in a different way.

Some people don't really understand it, and XPath for that matter, but there are many times you can do things with a single template, single XPath that would take dozens of lines of standard code.

 

[AtW]

XPath is like SQL, but less powerful. I much prefer Microsoft's LINQ - now that's proper thing, check it out here. This is like XPath but its really like SQL, yet with compile time checks, intellisense etc: awesome real-world application that will be successful.

 

[DimPrawn]

Looks like VB + XML for those that can't do XSLT.

HTH

 

[Joe Black]

Or more like a Java/C# combo with XPath, SQL and a smidgen of this and a smidgen of that, resulting in what appears to be a stew cooked up something rotten.

"XPath is like SQL, but less powerful"

XPath is in many ways more powerful than SQL, unless you're talking about TSQL or PL/SQL which are again essentially hacks added onto an idea to make it fit into something else rather than using it in a way that it was intended.

 

[bogeyman]

essentially hacks added onto an idea to make it fit into something else rather than using it in a way that it was intended.

Exactly JB. However, it always seems to happen that purist models (of anything, not just programming) need to be desecrated and bastardised before they are of remotely any use to 'ordinary' folk like me.

 

[AtW]

XPath is in many ways more powerful than SQL, unless you're talking about TSQL or PL/SQL which are again essentially hacks added onto an idea to make it fit into something else

Exactly - they added loops with breaks and continues, variables and other goodies to fit something else... real world tasks!. The fact is that such constructs were necessary, and in XSLT they make half arsed attempt to support it - they have loops, if statements and variables, but they are crippled thus requiring far more effort for simple things than it should be necessary.

And this parallel bullcrap - there are NO multithreading issues with local variables - they are isolated from anything so to disallow LOCAL variables on the basis of high performance (which XSLT can never deliver anyway - its not exactly going to be used for OS writing, so they might not have bothered).

Really bad that some tool that could have fit XML so nicely is in such a crippled state - very low adoption rate is not suprising. They can stick this functionality up their bottoms if they can't provide things that programmers are used to - don't try to remake people, just give them more efficient tools to do their jobs faster instead, leave pure research projects to where they belong - academia, not real world.

Anyhow I found ways to do what I wanted - it took far more lines than it was necessary to do these simple things.

 

[TheMonkey]

XSLT would be good if it wasn't so fecking slow. No implementations deal with siblings in a non-painfully slow fashion. Ironically, .Net's compiled transform is the most pitifully slow thing on the planet.

I'm currently working on something rather large that requires edge caching and some logic (purely in XSLT) on the edge to filter a master dataset that is sent out in XML. I pity Akamai who are going to have to run this chunk of code on their edge clusters.

 

[Cowboy Bob]

The Saxon API is pretty fast - http://saxon.sourceforge.net/ - it's written by the guy who invented XSLT. Available in Java and .NET flavours...

 

[DimPrawn]

That's looks pretty good CB