5 ms·

My "favorite" XML formats are the one that are just some kind of weird meta-format and don't really use any of the XML features: <format> <record id="

by bane 10y ago

My "favorite" XML formats are the one that are just some kind of weird meta-format and don't really use any of the XML features: <format> <record id="1"> <field name="id" value="1"/> <field name="name" value="abc">blah blah</field> <field name="attribute">this is the attribute value</field> <field name="end_of_record" value="True"/> </record> <record id="2"> ... </record> </format> And yes, these types of abominations are everywhere. The only way to avoid being called a Bozo when producing XML is to either a) ensure that humans never had to see this craziness b) don't use XML XML as a config file format, in particular, is probably one of the worst ideas in computing.

voltagex_ 10y ago
How would you write that example while taking advantage of the XML features you're talking about?
- bane 10y ago
  I think what you might be asking is "what would more idiomatic XML look like?" And that's a fair question for people who haven't spent lots of time working with XML. First off, I think attributes are evil. In theory, they're good, but nobody knows how to use them, so they shouldn't ever be part of your XML. They're simply elements with cardinality of 1. The format would probably be better as: <format> <record> <id>1</id> <name> abc <comment>blah blah</comment> </name> <attribute>this is the attribute value</attribute> </record> <record> ... </record> </format> This is a completely valid XML language, is much more clearer, less verbose, doesn't overload element names, doesn't abuse attributes, etc. etc. One important thing that most people don't get about XML is that XML is a specification for describing data-interchange formats. XML isn't a format, or a language. The result of following the XML spec is an "XML format". If somebody asks what format some data format is in, it's more appropriate to say "it's in an XML" rather than "it's in XML".
- lmm 10y ago
  Well this reduces to something like: <abc> blah blah <attribute>this is the attribute value</field> </abc> The point is not to write a flexible meta-format for expressing arbitrary objects, because XML is already that. Each specific thing you want to express should have its own specific format. That way you can actually use the validation features too.
mwfunk 10y ago
I don't necessarily disagree, except for the last point. I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly vs. using other tools or APIs to touch the file. In those cases, I would rather have XML config files than undocumented binary blobs as config files. When I see an XML config file, I feel a little relief that it's not a binary blob rather than disappointment that it's not freeform text, because I assume that freeform text must've been off the table for whatever reason (which, depending on what the config file is for, can be a totally rational and reasonable thing to do). I don't work in specialties where XML has a ton of visibility though- maybe there are lots of projects out there that I don't use in which people are required to hand-edit XML config files, as opposed to "it's in XML, so you could edit it directly, but really no one should be modifying the file with a text editor unless the preferred indirect mechanism isn't an option in some specific case".
- throwaway_java 10y ago
  yeah. What kind of nut-bag edits config files using a text editor.
- SomeCallMeTim 10y ago
  >In those cases, I would rather have XML config files than undocumented binary blobs as config files. False dichotomy. Better than XML and binary blobs: * JSON (assuming everyone knows what this is) * YAML [0] * Lua tables (if you're already using Lua as a scripting language; Lua started out as a configuration language after all) * INF format [1] (not my favorite, but pretty easy to parse and much better for humans to read than XML) * Any of the above compressed with a gzip compatible compression (if size matters, though it rarely does these days) Even Protocol Buffers [2] are better than XML, though at that point it becomes a "documented binary blob". But as long as the spec is shared, the format can easily be read by just about any programming language. [0] https://en.wikipedia.org/wiki/YAML https://en.wikipedia.org/wiki/YAML [1] https://en.wikipedia.org/wiki/INF_file https://en.wikipedia.org/wiki/INF_file [2] https://en.wikipedia.org/wiki/Protocol_Buffers https://en.wikipedia.org/wiki/Protocol_Buffers
  - 10y ago
brightball 10y ago
The biggest advantage of XML was the detailed schema validation. Having a uniform and flexible way to both generate data structures and ensure that their contents was valid before ever attempting to process them was handy. XML had a lot of warts but most of its strengths are still seeking passable implementations in JSON. Protocol Buffers is probably the closest thing to being standard in that area for schemas and generation. The number of JavaScript templating options out there are trying to fill the XSLT gap.
- bane 10y ago
  Yeah, I acknowledge that bit. But I also think the various schema definition languages (DFDs, XSD, whatever) turned out to be either not expressive enough (DFDs), or a complete PIA (XSD) and in the end, they weren't used very often. Still, it's nice to have them when you need them and when they aren't there it hurts.
  - brightball 10y ago
    I'll definitely agree with that. I remember using some Java desktop GUI to generate XSD's rather than typing all that stuff out.
  - Mikhail_Edoshin 10y ago
    Relax NG validation is very good; it's more expressive than XSD and it has both XML and non-XML forms and looks very nice.
- zamalek 10y ago
  It's also that it's extensible (primarily because of namespaces) - you can mix and match schemas so long as one of them uses xs:any. This brings up another way to avoid being called a bozo: namespace your XML. You're throwing a major advantage away if you don't, and if you don't need/understand that advantage then you're better off using a different serialization format.
voltagex_ 10y ago
Microsoft pretty much standardised on XML all through the early .NET framework - app.config and web.config, plus most project files are XML files, and defining your own configuration (past simple key/values) is very tricky and error-prone.
int_handler 10y ago
I'm sure you will also love JSONx: http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.ibm.dp.doc/json_jsonxconversionexample.html http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com....
- bane 10y ago
  There....that's a perfect example. Thank you.
- jarman 10y ago
  Well, if you have to store arbitrary, opaque JS object in XML document, it is much better way than JSON in CDATA
groovy2shoes 10y ago
You're going to "love" this little guy: http://txti.es/barry/xml http://txti.es/barry/xml Only slightly better is the JSON counterpart: http://txti.es/barry/json http://txti.es/barry/json
thom 10y ago
Here is an event from a popular sports data provider's XML format, for your delectation: <Event id="524717408" event_id="1" type_id="34" period_id="16" min="0" sec="0" team_id="20" outcome="1" x="0.0" y="0.0" timestamp="2014-11-30T12:29:59.446" last_modified="2014-11-30T13:24:03"> <Q id="2045368832" qualifier_id="59" value="23, 2, 21, 12, 6, 17, 8, 4, 19, 11, 10, 1, 3, 5, 7, 24, 28, 33" /> <Q id="1068483434" qualifier_id="227" value="0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0" /> <Q id="840260679" qualifier_id="197" value="425" /> <Q id="1586850783" qualifier_id="30" value="40383, 57328, 40146, 54756, 38580, 55605, 17339, 42774, 17784, 62399, 110979, 3673, 80447, 84395, 20452, 49596, 153366, 169359" /> <Q id="340265857" qualifier_id="44" value="1, 2, 2, 3, 2, 2, 3, 3, 4, 4, 4, 5, 5, 5, 5, 5, 5, 5" /> <Q id="328261435" qualifier_id="194" value="38580" /> <Q id="1426777221" qualifier_id="130" value="4" /> <Q id="293008363" qualifier_id="131" value="1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 0, 0, 0, 0, 0, 0, 0" /> </Event> XML and CSV, together at last.
- chme 10y ago
  Reminds me of the beautiful paths in svg: <path id="path4136" d="m 141.42136,428.08793 c 5.24568,-16.5136 15.9393,-31.24659 30.01423,-41.35166 14.07492,-10.10508 31.45369,-15.52663 48.77766,-15.21688 13.79473,0.24664 27.51957,4.08979 39.39595,11.11168 11.2946,6.67792 20.92213,16.25825 27.27185,27.74057 6.34973,11.48232 9.35256,24.85978 8.08349,37.91934 -0.97817,10.06598 -4.47673,19.87936 -10.10152,28.28427 -7.66405,11.4521 -18.89192,19.94346 -29.67188,28.52721 -10.77995,8.58374 -21.59293,17.81326 -27.90682,30.06164 -5.96111,11.56401 -7.38898,25.49638 -3.38484,37.87491 4.00414,12.37853 13.52214,22.96957 25.6082,27.78501 6.7156,2.67569 13.99861,3.58421 21.2132,4.04061 19.62989,1.24181 39.40632,-0.70279 58.58885,-5.05077 14.7604,-3.34565 29.1633,-8.0984 43.43656,-13.13198 20.00787,-7.05594 40.67497,-15.26376 54.54824,-31.31473 4.77196,-5.52102 8.57644,-11.80437 12.12183,-18.18274 19.76105,-35.55128 32.20013,-75.50916 33.33503,-116.16755 0.65168,-23.34676 -2.46779,-46.99293 -11.11168,-68.69037 -5.01987,-12.60061 -11.95904,-24.5794 -21.47642,-34.24345 -9.51738,-9.66404 -21.73721,-16.92383 -35.09212,-19.29463 -2.34449,-0.4162 -4.71259,-0.68237 -7.07107,-1.01016 -18.71745,-2.6014 -36.77133,-9.07291 -55.55839,-11.11167 -15.41222,-1.67253 -30.96773,-0.32564 -46.46701,0 -8.75302,0.1839 -17.50911,0.0413 -26.26397,0 -19.79058,-0.0933 -39.767,0.35345 -59.02055,4.93345 -19.25355,4.58001 -37.93007,13.61662 -51.08608,28.40158 -10.37036,11.65439 -16.79892,26.19465 -23.23351,40.4061 -3.97708,8.78379 -8.01783,17.53876 -12.12183,26.26397" style="opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:2;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />

by bane 10y ago

voltagex_ 10y ago

How would you write that example while taking advantage of the XML features you're talking about?

bane 10y ago
I think what you might be asking is "what would more idiomatic XML look like?" And that's a fair question for people who haven't spent lots of time working with XML. First off, I think attributes are evil. In theory, they're good, but nobody knows how to use them, so they shouldn't ever be part of your XML. They're simply elements with cardinality of 1. The format would probably be better as: <format> <record> <id>1</id> <name> abc <comment>blah blah</comment> </name> <attribute>this is the attribute value</attribute> </record> <record> ... </record> </format> This is a completely valid XML language, is much more clearer, less verbose, doesn't overload element names, doesn't abuse attributes, etc. etc. One important thing that most people don't get about XML is that XML is a specification for describing data-interchange formats. XML isn't a format, or a language. The result of following the XML spec is an "XML format". If somebody asks what format some data format is in, it's more appropriate to say "it's in an XML" rather than "it's in XML".
lmm 10y ago
Well this reduces to something like: <abc> blah blah <attribute>this is the attribute value</field> </abc> The point is not to write a flexible meta-format for expressing arbitrary objects, because XML is already that. Each specific thing you want to express should have its own specific format. That way you can actually use the validation features too.

mwfunk 10y ago

I don't necessarily disagree, except for the last point. I've rarely (never?) encountered XML used as a config file format where users were expected or encouraged to edit that config file directly vs. using other tools or APIs to touch the file. In those cases, I would rather have XML config files than undocumented binary blobs as config files. When I see an XML config file, I feel a little relief that it's not a binary blob rather than disappointment that it's not freeform text, because I assume that freeform text must've been off the table for whatever reason (which, depending on what the config file is for, can be a totally rational and reasonable thing to do). I don't work in specialties where XML has a ton of visibility though- maybe there are lots of projects out there that I don't use in which people are required to hand-edit XML config files, as opposed to "it's in XML, so you could edit it directly, but really no one should be modifying the file with a text editor unless the preferred indirect mechanism isn't an option in some specific case".

throwaway_java 10y ago
yeah. What kind of nut-bag edits config files using a text editor.
SomeCallMeTim 10y ago
>In those cases, I would rather have XML config files than undocumented binary blobs as config files. False dichotomy. Better than XML and binary blobs: * JSON (assuming everyone knows what this is) * YAML [0] * Lua tables (if you're already using Lua as a scripting language; Lua started out as a configuration language after all) * INF format [1] (not my favorite, but pretty easy to parse and much better for humans to read than XML) * Any of the above compressed with a gzip compatible compression (if size matters, though it rarely does these days) Even Protocol Buffers [2] are better than XML, though at that point it becomes a "documented binary blob". But as long as the spec is shared, the format can easily be read by just about any programming language. [0] https://en.wikipedia.org/wiki/YAML https://en.wikipedia.org/wiki/YAML [1] https://en.wikipedia.org/wiki/INF_file https://en.wikipedia.org/wiki/INF_file [2] https://en.wikipedia.org/wiki/Protocol_Buffers https://en.wikipedia.org/wiki/Protocol_Buffers
- 10y ago

brightball 10y ago

The biggest advantage of XML was the detailed schema validation. Having a uniform and flexible way to both generate data structures and ensure that their contents was valid before ever attempting to process them was handy. XML had a lot of warts but most of its strengths are still seeking passable implementations in JSON. Protocol Buffers is probably the closest thing to being standard in that area for schemas and generation. The number of JavaScript templating options out there are trying to fill the XSLT gap.

bane 10y ago
Yeah, I acknowledge that bit. But I also think the various schema definition languages (DFDs, XSD, whatever) turned out to be either not expressive enough (DFDs), or a complete PIA (XSD) and in the end, they weren't used very often. Still, it's nice to have them when you need them and when they aren't there it hurts.
- brightball 10y ago
  I'll definitely agree with that. I remember using some Java desktop GUI to generate XSD's rather than typing all that stuff out.
- Mikhail_Edoshin 10y ago
  Relax NG validation is very good; it's more expressive than XSD and it has both XML and non-XML forms and looks very nice.
zamalek 10y ago
It's also that it's extensible (primarily because of namespaces) - you can mix and match schemas so long as one of them uses xs:any. This brings up another way to avoid being called a bozo: namespace your XML. You're throwing a major advantage away if you don't, and if you don't need/understand that advantage then you're better off using a different serialization format.

voltagex_ 10y ago

Microsoft pretty much standardised on XML all through the early .NET framework - app.config and web.config, plus most project files are XML files, and defining your own configuration (past simple key/values) is very tricky and error-prone.

int_handler 10y ago

I'm sure you will also love JSONx: http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.ibm.dp.doc/json_jsonxconversionexample.html http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com....

bane 10y ago
There....that's a perfect example. Thank you.
jarman 10y ago
Well, if you have to store arbitrary, opaque JS object in XML document, it is much better way than JSON in CDATA

groovy2shoes 10y ago

You're going to "love" this little guy: http://txti.es/barry/xml http://txti.es/barry/xml Only slightly better is the JSON counterpart: http://txti.es/barry/json http://txti.es/barry/json

thom 10y ago

Here is an event from a popular sports data provider's XML format, for your delectation: <Event id="524717408" event_id="1" type_id="34" period_id="16" min="0" sec="0" team_id="20" outcome="1" x="0.0" y="0.0" timestamp="2014-11-30T12:29:59.446" last_modified="2014-11-30T13:24:03"> <Q id="2045368832" qualifier_id="59" value="23, 2, 21, 12, 6, 17, 8, 4, 19, 11, 10, 1, 3, 5, 7, 24, 28, 33" /> <Q id="1068483434" qualifier_id="227" value="0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0" /> <Q id="840260679" qualifier_id="197" value="425" /> <Q id="1586850783" qualifier_id="30" value="40383, 57328, 40146, 54756, 38580, 55605, 17339, 42774, 17784, 62399, 110979, 3673, 80447, 84395, 20452, 49596, 153366, 169359" /> <Q id="340265857" qualifier_id="44" value="1, 2, 2, 3, 2, 2, 3, 3, 4, 4, 4, 5, 5, 5, 5, 5, 5, 5" /> <Q id="328261435" qualifier_id="194" value="38580" /> <Q id="1426777221" qualifier_id="130" value="4" /> <Q id="293008363" qualifier_id="131" value="1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 0, 0, 0, 0, 0, 0, 0" /> </Event> XML and CSV, together at last.

chme 10y ago
Reminds me of the beautiful paths in svg: <path id="path4136" d="m 141.42136,428.08793 c 5.24568,-16.5136 15.9393,-31.24659 30.01423,-41.35166 14.07492,-10.10508 31.45369,-15.52663 48.77766,-15.21688 13.79473,0.24664 27.51957,4.08979 39.39595,11.11168 11.2946,6.67792 20.92213,16.25825 27.27185,27.74057 6.34973,11.48232 9.35256,24.85978 8.08349,37.91934 -0.97817,10.06598 -4.47673,19.87936 -10.10152,28.28427 -7.66405,11.4521 -18.89192,19.94346 -29.67188,28.52721 -10.77995,8.58374 -21.59293,17.81326 -27.90682,30.06164 -5.96111,11.56401 -7.38898,25.49638 -3.38484,37.87491 4.00414,12.37853 13.52214,22.96957 25.6082,27.78501 6.7156,2.67569 13.99861,3.58421 21.2132,4.04061 19.62989,1.24181 39.40632,-0.70279 58.58885,-5.05077 14.7604,-3.34565 29.1633,-8.0984 43.43656,-13.13198 20.00787,-7.05594 40.67497,-15.26376 54.54824,-31.31473 4.77196,-5.52102 8.57644,-11.80437 12.12183,-18.18274 19.76105,-35.55128 32.20013,-75.50916 33.33503,-116.16755 0.65168,-23.34676 -2.46779,-46.99293 -11.11168,-68.69037 -5.01987,-12.60061 -11.95904,-24.5794 -21.47642,-34.24345 -9.51738,-9.66404 -21.73721,-16.92383 -35.09212,-19.29463 -2.34449,-0.4162 -4.71259,-0.68237 -7.07107,-1.01016 -18.71745,-2.6014 -36.77133,-9.07291 -55.55839,-11.11167 -15.41222,-1.67253 -30.96773,-0.32564 -46.46701,0 -8.75302,0.1839 -17.50911,0.0413 -26.26397,0 -19.79058,-0.0933 -39.767,0.35345 -59.02055,4.93345 -19.25355,4.58001 -37.93007,13.61662 -51.08608,28.40158 -10.37036,11.65439 -16.79892,26.19465 -23.23351,40.4061 -3.97708,8.78379 -8.01783,17.53876 -12.12183,26.26397" style="opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:2;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />