Fun with xslt...

[usernamenumber]

One of my specialties at work is an xml dialect that describes how to turn documents written in another arbitrary xml dialect into another-other arbitrary xml dialect. I swear if this gets any more meta, I'm going to gain the power to alter reality around me with my text editor.

Which would be pretty cool.

Comments

[wombatbanana.livejournal.com]

I've been playing around with using XSLT → SVG+JavaScript to generate interactive charts. It's fun stuff.

[usernamenumber.livejournal.com]

Ooh neat. What format is the source data in, plain old xml?

[wombatbanana.livejournal.com]

I've mostly been dealing with Bugzilla's XML export format (e.g. http://bugzilla/show_bug.cgi?ctype=xml&id=1&id=2&...&id=n), hand-annotated with some extra information. But anything that isn't in XML to being with can be massaged into one-off "XML" (e.g. <value time="2009-12-22T00:00:00Z" count="5"/>.)

[laurion]

I've not had to muck with it, but I've seen the internals of such a process looking at the course conversion scripts that convert from Blackboard to Moodle. Suffice to say, it -isn't- pretty, and isn't helped by the fact that Blackboard is reluctant to provide any useful information on their file and data structures.

Metas hacked!

[metahacker.livejournal.com]

At my old company, we had a program written in...err... I forget, but some vaguely obscure language which took user input and used it to generate XSLT to translate between XML dialects.

The XML, of course, was usually being used as an intermediary language between two other languages (facepalm).

[usernamenumber.livejournal.com]

I don't use vi. Not for xml, anyway. :P

I don't use emacs, either. Long live jedit!

[usernamenumber.livejournal.com]

Sure. We produce courseware in html and pdf formats. Writing it in xml gives us the ability to separate content from presentation and xslt lets us translate it into those and other formats while maintaining a single source.

[usernamenumber.livejournal.com]

I could be missing a lot here, as I've only worked with JSON as a way to transmit data between components of an AJAX app. But here's my attempt to respond, with corrections and counter-examples welcome.

For starters, there are already a huge number of tools out there for XML. Docbook comes with stylesheets for converting to any number of formats, which we have only to extend for our purposes. That's not really a quality of the language per se, but it is a valid practical consideration.

Then there are things like xpath, which make it possible to do (at least from what I can tell) much more powerful searches of an xml document than of the same data in the JSON libraries I've seen, which basically just import the JSON into native data types and that's that. It seems to me that storing data as an array or basic object is simple, but limiting. For example, how would I say "retrieve all elements of type foo that are nested one or more levels below elements of type bar and have the property baz set to 'hi!'" ("//bar//foo[@baz='hi!']" in xpath) using JSON tools without having to write my own function to iterate over the data? (note: it actually looks like there has been some work to implement xpath for JSON, but only in a couple of languages and not ones I use, so I'm not counting it :P)

Setting tools aside, though, looking at the JSON/XML comparisons on the JSON site, I don't really see it as being that much more "lightweight", at least in terms of producing it. I mean, just looking at the first example, the difference in character counts is only about 5%. Plus, I can't imagine the JSON equivalent of something like:

<para>
The <filename>/etc/passwd</filename> file contains user account definitions. One way to view its contents is with the <command>cat</command> command as follows:
</para>
<screen><prompt>[user@host ~]$</prompt> <userinput>cat /etc/passwd</userinput>
<computeroutput>root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
... etc ...
</computeroutput></screen>

being less cumbersome than the xml version. I can see JSON being good for describing objects, but it doesn't seem to be a good fit for actual pages worth of prose with inline formatting information. Counter-examples welcome, though.

[usernamenumber.livejournal.com]

...and on that point I would not disagree. :)