XSLT is a failure wrapped in pain • Hacker News Board

Re: XSLT is a failure wrapped in pain

#151

Post by jgalt212 » Sat, Dec 06, 2014, 11:49 PM UTC

ohyesyodo wrote: post #61

jgalt212 wrote: post #52

Earlier quoted context omitted.

I don't know if you're trolling, but here's how I'd do it in Python import xml.etree.ElementTree as ET tree = ET.parse('data.xml') new_tree = my_transform(tree) new_tree.write("output.xml")

I'm not sure if you are trolling, but you left out the actual transform. In my experience, XSLT feels optimized towards transforms, which most other languages aren't. I also dislike XSLT, but whenever I do things like this in Python, C# or C++ it tends to get more messy then my XLTS when the transforms are nontrivial.

I'm getting downvotes here? Obviously, not from ohyesyodo b/c he does not have enough karma to allocate downvotes.

Re: XSLT is a failure wrapped in pain

#152

Post by ultimape » Sat, Dec 06, 2014, 11:59 PM UTC

coldnebo wrote: post #95

hyp0 wrote: post #87

Earlier quoted context omitted.

There have been several JSON transformation tools, but they haven't taken off. ( EDIT in general, not just for transformation,) when a task gets too complex for JSON, it's easier to switch to XML. Thus: XML protects JSON. But I agree there is some pressure on JSON. And if someone can come up with a way to do schema and transformation that isn't complex, it will be adopted like crazy. Counter-point: (1) all the cool k…

There is a lot of confusion between typing systems, metatyping systems (that can implement arbitrary type systems) and the transport representation of such systems. I agree with your counterpoints, but the cool kids are still having issues with transport representation of arbitrary types. Sure (eg Ruby) can use Kernel dump and load to marshall arbitrary types, but what happens when the other end doesn't have the type…

I'm a fan of the techniques as described in : http://smile.amazon.com/Expert-Business-Objects-Books-Profes...

Basically, it uses the underlying runtime to serialize the entire object to the other machine. The theory being, if object oriented programming ties data to functions, why not ship both over the wire?

It works really well with the micro-services paradigm.

Not exactly a 100% solution, but it does solve the issues at least among the languages the runtime supports.

Re: XSLT is a failure wrapped in pain

#153

Post by ultimape » Sun, Dec 07, 2014, 12:10 AM UTC

coldnebo wrote: post #86

grndn wrote: post #62

The problems that XML and XSLT address have not gone away. It saddens me when the XML-hating JSON community starts reinventing solutions that have all the same issues of bloat and complexity (see JSON schema, Collection+JSON, Siren, etc). I would not be surprised if someone soon announces a "JSON Transformation" tool that can convert one JSON schema to another. Followed shortly by a standard for JSON namespaces so yo…

Flashback to the early days of XML: "oh god, why would anyone use something as bloated and slow as CORBA to define an interface! Look how simple XML is, and it's human readable!!" CORBA is laughing its head off: "Who's bloated and overly complex now, eh?" XML: "Well at least I developed an appreciation of the problem domain... Unlike those arrogant JSON kids" CORBA: "You were the same way at their age." XML: "Sure wa…

I've been actively staying away from CORBA myself.

Back in college, we tried our hand at using Ice http://www.zeroc.com/iceVsCorba.html and it seemed to do the trick.

Still, it does assume that both parties have access to the template generated by ice - thus going back to the issues surrounding needing a sort of schema.

That being said, there does seem to be options for interacting using json: http://ice2rest.make-it-app.com/ and as of 3.3.1 it apparently supports Google's Protocol Buffers for flexibility.

Re: XSLT is a failure wrapped in pain

#154

Post by lsaferite » Sun, Dec 07, 2014, 12:22 AM UTC

brokentone wrote: post #104

Reminds me of the person (people, team, etc) who decided it was a good idea to code websites in XML + XSLT. Because XHTML is just not good enough. The most prominent of these (I'm shocked it's still this way) is http://www.skechers.com/

Why are you shocked? Investing in a software stack for a website is non-trivial. If it's working for them then it's throwing money away to change it right now.

Re: XSLT is a failure wrapped in pain

#155

Post by scrollaway » Sun, Dec 07, 2014, 12:58 PM UTC

personZ wrote: post #149

scrollaway wrote: post #122

Earlier quoted context omitted.

> Hey, sorry that those bank transfer got lost, but it turns out that we mistyped the account number field name and the destination system just ate it. The JSON approach does not give you everything-and-the-kitchen-sink. A lot of people consider that a feature. If you want to do schema validation on top of json messages, you're free to do it when you receive them - the data format does not prevent you from that, it m…

It's a simple data format and needs no new feature. XSLT was developed entirely independently of XML. XML Schemas were developed entirely independently of XML. XML itself is absurd simple. It is the epitome of simple. But you build an ecosystem of tools and standards around it. And that is of course already happening in JSON -- JSON Schemas, for instance, are now a thing.

> XML itself is absurd simple. It is the epitome of simple.

I can't possibly argue with you if you actually believe that. XML is not simple. XML has CDATA, DOCTYPEs, comments, attributes, significant whitespace and so much more which JSON does not have.

Re: XSLT is a failure wrapped in pain

#156

Post by ohyesyodo » Mon, Dec 08, 2014, 2:02 PM UTC

jgalt212 wrote: post #151

ohyesyodo wrote: post #61

Earlier quoted context omitted.

I'm not sure if you are trolling, but you left out the actual transform. In my experience, XSLT feels optimized towards transforms, which most other languages aren't. I also dislike XSLT, but whenever I do things like this in Python, C# or C++ it tends to get more messy then my XLTS when the transforms are nontrivial.

I'm getting downvotes here? Obviously, not from ohyesyodo b/c he does not have enough karma to allocate downvotes.

You are probably getting downloads from the fact that your response did not make any sense.

Re: XSLT is a failure wrapped in pain

#157

Post by jgalt212 » Thu, Dec 11, 2014, 2:53 AM UTC

ohyesyodo wrote: post #156

jgalt212 wrote: post #151

Earlier quoted context omitted.

I'm getting downvotes here? Obviously, not from ohyesyodo b/c he does not have enough karma to allocate downvotes.

You are probably getting downloads from the fact that your response did not make any sense.

If you know Python, my response make perfect sense, in that it's easy to transform xml string -> python tree -> new python tree -> new xml string or json string or csv string.