XML OF DEATH [entries|reading|network|archive]
simont

[ userinfo | dreamwidth userinfo ]
[ archive | journal archive ]

Tue 2006-10-17 11:36
XML OF DEATH

If you're designing an XML representation of some type of data, and you want a key-value sort of organisation, this is inherently reasonably well supported by XML. If you want to set the key ‘foo’ to the value ‘bar’, you can simply set up your DTD so that it lets you write

<sometagorother foo=bar />

Now occasionally I can understand that you might want to layer your own key-value structure on top of this:

<set key="foo" value="bar" />

because this approach gives you the ability to add extra attributes alongside each key/value pair, which might be useful for all sorts of vaguely sensible reasons: expiry dates, permissions, conditionalisation, you name it. Also it doesn't require you to specify the full set of possible keys in the DTD, which is obviously useful.

However, when I see a third layer of key-value structure on top of even that …

<method name="SetVariable">
<arg key="name" value="foo" />
<arg key="value" value="bar" />
</method>

… I really do start to wonder whether someone's brain has been EATEN BY PARASITIC XML MEMES OF DEATH.

LinkReply
[identity profile] ptc24.livejournal.comTue 2006-10-17 10:59
    <method name="SetVariable">
        <arg key="name">foo</arg>
        <arg key="value">bar</arg>
    </method>


would make some sense. A little. But even then it's less than ideal.

I was going to do an XXML ("eXtensible XML Markup Lanuagage") spoof which has various layers of unnecessary nesting once, but I think that XSLT beat me to it.
Link Reply to this | Thread
[personal profile] simontTue 2006-10-17 11:04
The XML file in question, it turns out, does not have any text that isn't inside a tag, anywhere at all. It wouldn't surprise me at all to find that the DTD made it unconditionally illegal.
Link Reply to this | Parent
[identity profile] oneplusme.livejournal.comTue 2006-10-17 17:00
XSLT does not merely make the baby Jesus cry, but actively seeks out his ancestors and anally violates them with pointy brackets. I swear I'll never, ever call COBOL verbose again.

<xsl:if test="$pain &gt; $painthreshold">
OWMAKEITSTOP
<xsl:else/>
Subtract 1d20 from SAN and write another line of XSL
</if>

...and then I get to code data import tools at $ORKPLACE that have to generate XSL on the fly to apply to the 50MB+(!) XML files some idiot provider has decided to send our way because the equivalent 200kB of CSV just isn't cool enough these days.

Meanwhile, large companies begin to seriously suggest XML-processing FPGAs as the answer to all this lunacy, which seems somewhat akin to attempting to help a drowning swimmer using a wave machine.

Then again, XML does have one huge advantage: it's not EDIFACT.
Link Reply to this | Parent | Thread
[identity profile] jvvw.livejournal.comTue 2006-10-17 21:14
Ooh, I hate XSLT so so much. I wish I didn't have to use it.
Link Reply to this | Parent
[personal profile] pm215Tue 2006-10-17 21:59
So do you have a recommendation other than XSLT for processing XML? I ask because there's a project in the offing where you feed in some documentation in an XML kind of format and it spits out docbook/html/C headers/any of half a dozen other output formats, and we're wondering whether to do XSLT or something else (eg a program written in some language with DOM bindings which just does this kind of thing programmatically).
Link Reply to this | Parent | Thread
[identity profile] oneplusme.livejournal.comTue 2006-10-17 22:17
To be fair to it, XSLT works pretty well for its intended purpose (it's just a huge memory hog, and the syntax will wear your fingers to the bone). My rant was one of semi-affectionate frustration, if you will...

However, if it starts looking like your problem will be tricky (or hideously long-winded) to solve in XSLT, it's probably best to cut your losses and just code something yourself with a DOM or a SAX parser.
Link Reply to this | Parent
[identity profile] pjc50.livejournal.comTue 2006-10-17 11:43
Is this RDF, or some sui generis hideousness?
Link Reply to this | Thread
[personal profile] simontTue 2006-10-17 12:14
This is a company-internal thing. Why, does RDF perpetrate a similar horror?
Link Reply to this | Parent | Thread
[identity profile] mtbc100.livejournal.comTue 2006-10-17 14:00
A little RDF file (http://smi-protege.stanford.edu/svn/protege-core/trunk/examples/rdf/MotorVehicle.rdf?rev=58&sortby=rev&view=markup)
Link Reply to this | Parent
[identity profile] uisgebeatha.livejournal.comTue 2006-10-17 11:53
XML makes baby Jesus cry.

I never could quite get the hang of it, what with all that DTD and XSLT nonsense. Too many rules, if you ask me. :P
Link Reply to this | Thread
[personal profile] simontTue 2006-10-17 12:32
XML makes baby Jesus cry

Well, yes, that too. I can't see a convincing reason why the data in question here should ever have been represented in XML. I've got no serious problem with XML when it's being used as a markup language – it's no worse than HTML and easier to write third-party data-mining scripts for – but using it as a general framework in which to represent hierarchical data and (worse still) procedural programs is Just Wrong.
Link Reply to this | Parent | Thread
[identity profile] pjc50.livejournal.comTue 2006-10-17 14:21
It could be worse. Our software has at least 7 different lex/yacc parsers in it for various file formats, most of which have slightly underspecced syntax and vastly underspecced semantics. XML would by comparison be a blessing: one, and only one parser, from which data can be extracted easily by OO code. The files would be huge, but the existing formats aren't all that great sizewise.
Link Reply to this | Parent
[identity profile] mtbc100.livejournal.comTue 2006-10-17 14:03
Heh, yesterday I discovered XER, for encoding ASN.1 in XML.
Link Reply to this | Parent
[identity profile] tackline.livejournal.comTue 2006-10-17 12:34
To be fair, SQL schemas often go a similar way. What they don't do is complete muppetry like this (http://jakarta.apache.org/commons/jelly/).
Link Reply to this
navigation
[ go | Previous Entry | Next Entry ]
[ add | to Memories ]