Programmer Humor

32557 readers

380 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.

founded 5 years ago

MODERATORS

[email protected]

1232

AI's take on XML (lemmy.world)

submitted 2 months ago by [email protected] to c/[email protected]

134 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 9 points 2 months ago (2 children)

I think we did a thread about XML before, but I have more questions. What exactly do you mean by "anything can be a tag"?

It seems to me that this:

<address>
    <street_address>21 2nd Street</street_address>
    <city>New York</city> 
    <state>NY</state>
    <postal_code>10021-3100</postal_code>
</address>

Is pretty much the same as this:

  "address": {
    "street_address": "21 2nd Street",
    "city": "New York",
    "state": "NY",
    "postal_code": "10021-3100"
  },

If it branches really quickly the XML style is easier to mentally scope than brackets, though, I'll give it that.

[–] [email protected] 2 points 2 months ago* (last edited 2 months ago) (1 children)

Since XML can have attributes and children, it's not as easy to convert to JSON.

Your JSON example is more akin to:

<address street_address="21 2nd Street" city="New York" ...></address>

[–] [email protected] 3 points 2 months ago* (last edited 2 months ago) (1 children)

Hmm, so in tree terms, each node has two distinct types of children, only one of which can have their own children. That sounds more ambiguity-introducing than helpful to me, but that's just a matter of taste. Can you do lists in XML as well?

[–] [email protected] 2 points 2 months ago

No arrays are not allowed. Attributes can only be strings. But the children are kind of an array.

[–] [email protected] 1 points 2 months ago* (last edited 2 months ago) (1 children)

I'm not sure now that I think about it, but I find this more explicit and somehow more free than json. Which can't be true, since you can just

{"anything you want":{...}}

But still, this:

<my_custom_tag>
<this> 
<that>
<roflmao>
...

is all valid.

You can more closely approximate the logical structure of whatever you're doing without leaving the internal logic of the... syntax?

<car>
<tyre> air, <valve>closed</valve>  </tyre>
<tyre> air, <valve>closed</valve>  </tyre>
<tyre>      <valve>open</valve>  </tyre>
<tyre> air, <valve>closed</valve>  </tyre>
</car>

Maybe I just like the idea of a closing tag being very specific about what it is that is being closed (?). I guess I'm really not sure, but it does feel nicer to my brain to have starting and closing tags and distinguishing between what is structure, what is data, what is inside where.

My peeve with json is that... it doesn't properly distinguish between strings that happen to be a number and "numbers" resulting in:

myinput = {"1":"Hello",1:"Hello"}
tempjson = json.dumps(myinput)
output = json.loads(tempjson)
print(output)
>>>{'1': 'Hello'}

in python.

I actually don't like the attributes in xml, I think it would be better if it was mandatory that they were also just more tagged elements inside the others, and that the "validity" of a piece of xml being a certain object would depend entirely on parsing correctly or not.

I particularly hate the idea of attributes in svg, and even more particularly the way they defined paths.

https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths#curve_commands

It works, but I consider that truly ugly. And also I don't understand because it would have been trivial to do something like this:

<path><element>data</element><element>data</element></path>

[–] [email protected] 2 points 2 months ago* (last edited 2 months ago)

Maybe I just like the idea of a closing tag being very specific about what it is that is being closed (?).

That's kind of what I was getting at with the mental scoping.

My peeve with json is that… it doesn’t properly distinguish between strings that happen to be a number and “numbers"

Is that implementation-specific, or did they bake JavaScript type awfulness into the standard? Or are numbers even supported - it's all binary at the machine level, so I could see an argument that every (tree) node value should be a string, and actual types should be left to higher levels of abstraction.

I actually don’t like the attributes in xml, I think it would be better if it was mandatory that they were also just more tagged elements inside the others, and that the “validity” of a piece of xml being a certain object would depend entirely on parsing correctly or not.

I particularly hate the idea of attributes in svg, and even more particularly the way they defined paths.

I agree. The latter isn't even a matter of taste, they're just implementing their own homebrew syntax inside an attribute, circumventing the actual format, WTF.