Xsl

[TheMonkey]

That indeedy does.

I'll have a play with that.

I've been using XsltCompiledTransforms which just suck dick completely.

 

[AtW]

XSLT would be good if it wasn't so fecking slow. No implementations deal with siblings in a non-painfully slow fashion.

Surely not! Apparently its a functional language that sacrified variables and loops in order to achieve maximum degree of parellel execution!!!!!

Saxon is way too heavy, .NET's seems to work okayish though many functions are not supported in it - looks like XSLT guys committed suicide by making long list of very useful things optional, which means of course its not implemented by almost anyone.

 

[Cowboy Bob]

Saxon is way too heavy, .NET's seems to work okayish though many functions are not supported in it - looks like XSLT guys committed suicide by making long list of very useful things optional, which means of course its not implemented by almost anyone.

First you complain about lack of features, then you complain about a parser that has too many

 

[AtW]

First you complain about lack of features, then you complain about a parser that has too many

I complain about stardard making them optional - this means not all vendors implemented them, for example Microsoft .NET features pretty much barebones implementation that nevertheless qualifies as XSLT.

 

[Cowboy Bob]

I complain about stardard making them optional - this means not all vendors implemented them, for example Microsoft .NET features pretty much barebones implementation that nevertheless qualifies as XSLT.

Not implementing features is a Microsoft trend that you become used to

 

[AtW]

It is fault of the standard - real world implementors always go for the lowest possible standard that would still allow them to apply given label to product, for example look at SATA II - lots of optional specs, not all drives implement all of them, but manufactures love calling their drives SATA II even though they implement few features.

I repeat - its the fault of the stanard to make a bunch of key functions optional. Who suffers? Whoever designed the language - it hits adoption rates of XSLT and now that I have used it beyond simple examples I can understand why.

 

[TheMonkey]

AtW: btw I wholly agree with you on all points here.

 

[AtW]

Too right monkey - whoever designed XSL should be beheaded, lets just recap some of the key points they don't tell you upfront:

1) you can't have variables (only constats)
2) you can't break out of loops
3) you can't return results from "procedures"
4) you can't convert tree chunk into node-set without calling implementor's specific function (usually node-set) (the twats!!!)
5) you are basically fked as the whole model is too static - you can't for example make up dynamicaly piece of template and execute it
6) you can't use variables in Xpath bits to specify variable Attribute or Element names - they (constants wrongly referred to as vars) for values
7) you will waste most of the time looking for fked in the head workarounds to things that can be trivially and quickly done if they (at least!) had proper variables!

Conclusion:
XSLT is S**T DESIGN!

Sadly no good alternative for something similarly flexibly with XML and safe from execution point of view (no access to filesystem etc). What a waste of opportunity this is.

 

[AtW]

Let me just say it again - FFS, what kind of retard thought it was great idea to NOT allow changing variables? I mean FFS, if it hits performance so much (can't multithread due to dependencies) fine, issue warning to programmer so that he knows he may lose performance, fine, but FFS, let the programmer decide what's best and how to do the job, don't fking babysit him in the worst possible way - I always thought Pascal was crap, but now I think it is the best designed language ever, comparing to XSLT of course.

 

[_V_]

Too right monkey - whoever designed XSL should be beheaded, lets just recap some of the key points they don't tell you upfront:

1) you can't have variables (only constats)
2) you can't break out of loops
3) you can't return results from "procedures"
4) you can't convert tree chunk into node-set without calling implementor's specific function (usually node-set) (the twats!!!)
5) you are basically fked as the whole model is too static - you can't for example make up dynamicaly piece of template and execute it
6) you can't use variables in Xpath bits to specify variable Attribute or Element names - they (constants wrongly referred to as vars) for values
7) you will waste most of the time looking for fked in the head workarounds to things that can be trivially and quickly done if they (at least!) had proper variables!

Conclusion:
XSLT is S**T DESIGN!

Sadly no good alternative for something similarly flexibly with XML and safe from execution point of view (no access to filesystem etc). What a waste of opportunity this is.

And all of this IS BY DESIGN!!!!!!

XSLT is a functional not a procedural language.

HOW MANY MORE TIMES!!!!!!!!