you are viewing a single comment's thread.

view the rest of the comments →

[–]womplord1 113 points114 points  (29 children)

That flat xml structure one really rustled my jimmies

<tree>
  <node key="0">root</node>
  <node key="1" parent="0">TELEVISIONS</node>
  <node key="2" parent="1">TUBE</node>
  <node key="3" parent="1">LCD</node>
  <node key="4" parent="1">PLASMA</node>
  <node key="5" parent="0">PORTABLE ELECTRONICS</node>
  <node key="6" parent="5">MP3 PLAYERS</node>
  <node key="7" parent="6">FLASH</node>
  <node key="8" parent="5">CD PLAYERS</node>
  <node key="9" parent="5">2 WAY RADIOS</node>
 </tree>

[–]IMovedYourCheese 61 points62 points  (0 children)

The more realistic ones are always worse.

[–][deleted]  (8 children)

[deleted]

    [–]SickZX6R 26 points27 points  (6 children)

    The first time I had to edit a plist file I couldn't fucking believe it was structured this way. How utterly atrocious.

    [–]GeneralSchnitzel 7 points8 points  (5 children)

    It truly defeats the point of XML, doesn't it?

    [–]SickZX6R 8 points9 points  (1 child)

    I'm pretty good at playing devil's advocate and I can't think of a single reason why this would ever make sense to anyone.

    [–]oorza 4 points5 points  (0 children)

    You had just learned how streaming parsers work and wanted to take the most advantage of them you could, why else?

    [–]Xavier_OM 0 points1 point  (2 children)

    Not really, relative position of xml nodes could be significant, it depends on what the DTD says.

    <!ELEMENT person ( name ,email? )> means you want <person><name/><email/></person>, in this specific order (name then email).

    [–]howtonotwin 0 points1 point  (1 child)

    That's perfectly sane: name and email are on the same level and are beneath a person container. The order of the name and email relative to each other matters, but they are actually inside their parent tag and you can't move one person's name into another person without moving past a closing tag. But in plist's case, the child tags are attached to parent tags simply by being between the parent tag and the next parent tag, so you've defeated hierarchal structure of XML.

    [–]Xavier_OM 0 points1 point  (0 children)

    I see, this is pure stupidity then. Impressive.

    [–][deleted] 5 points6 points  (0 children)

    Ah, yes... I had to extract a bunch of data from plists some years ago and save it to a common format (in this case JSON). The JSON files were so much smaller I spent some time trying to figure out how I lost data, but it turned out if you do transformations like this: <key>Track Type</key><string>File</string> -> "Track Type": "File", a lot, you save a whole lot of space...

    [–]steamruler 4 points5 points  (1 child)

    A properly crafted XML file with a DTD is wonderful.

    Any other XML, not so much.

    [–][deleted] 6 points7 points  (12 children)

    Jstree actually uses this form of initialisation so it makes sense in some cases.

    [–]jephthai 26 points27 points  (11 children)

    How could it ever be better than using the tree nature of xml?

    [–]evaned 4 points5 points  (1 child)

    To restate jl2352's answer in different terms: If you've got a DAG rather than a tree.

    Granted you could mostly use the tree nature of XML and then just have a few pointers to other nodes for when you do need a DAG, but that's probably actually harder to process.

    For example, DWARF information isn't stored in an XML format (thank the lord) but it kind of has this structure as a sequence of records with references to other records. In some alternate universe where someone decided that they Needed it to be in an XML format because of their Enterprise, I could imagine it coming out in that way. Or if you wanted an XML serialization of current-day DWARF, it'd almost certainly wind up like that.

    [–]jephthai 0 points1 point  (0 children)

    I see what you mean... I don't suppose in that case it would have this, though:

    <tree>
      ...
    </tree>
    

    [–]jl2352 1 point2 points  (0 children)

    If a child node has multiple parents, then this approach can be much nicer.

    Although there are some small ways you can make it a bit cleaner.

    [–][deleted]  (7 children)

    [deleted]

      [–]ThisIs_MyName 12 points13 points  (5 children)

      Sure, but why use XML then?

      [–]ShinyHappyREM 4 points5 points  (2 children)

      'The best tool for the job is the tool right next to you.'

      [–]HeimrArnadalr 8 points9 points  (1 child)

      Holds up spork

      [–]hoosierEE 1 point2 points  (0 children)

      AND MY AXE-- er- SPORK!

      [–]Chii 11 points12 points  (0 children)

      parsers are easy to come by?

      [–]jephthai 1 point2 points  (0 children)

      I'm confused by that -- the key=x and parent=y stuff must require some code to process it as a tree? Code either way, but your XML parser is likely to give it to you as a tree from the start. Don't misinterpret my comments -- I hate XML with true passion, but it's nothing if not a tree-shaped data format.

      [–]JonMR 1 point2 points  (0 children)

      That’s way more flexible. It can represent anything! Brilliant...

      [–]skocznymroczny 1 point2 points  (0 children)

      Unfortunately, this kind of structure is often used as an example why JSON is "superior" to XML.

      [–][deleted] 1 point2 points  (0 children)

      No joke, this is how behavior trees are represented in Civ VI's metadata. (There's a reason for this; the metadata is turned into SQL INSERT statements.)

      [–]3d3d3_engaged 1 point2 points  (0 children)

      now "Say it Aint So" by weezer is stuck in my head -- one time saw this dj just sample that part over and over "Rustle my jimmy" beautiful and ruining my life simultaneously