Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Avoid Being Called a Bozo When Producing XML (2005)

hsivonen.fi

Post reply on HN
Print view View original

231–240 of 255 posts

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#231

Post by Mikhail_Edoshin »

wtbob wrote: post #42
cptskippy wrote: post #18

XML is well regarded in the enterprise and languages like JAVA, C#, and VB.NET handle is spectacularly as an exchange format. I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. I recall working with a partner who we were doing an identity federation with. Our system was using WS-Trust which is a SOAP/XML protocol. It wasn't ideal but everyone seemed to…

> I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. On the contrary, I think that XML's bad reputation comes from the fact that it is so incredibly verbose . Also, the whole child/attribute dichotomy is a huge, huge mistake. I've been recently dealing with the XDG Menu Specification, and it contains a child/attribute design failure, one which would ha…

The creators of XML were aware that it was verbose; they mention in their design goals that this was the least priority.

Child and attribute "dichotomy" is not a mistake. What you mean is that these two samples appear to be equivalent:

    
    123
But they are not equivalent. The first line (with an attribute) is there solely for the computer. When the document is rendered, the human user is not supposed to see anything there unless the computer adds it.

The second line (with text content) is there for both the computer and the human user. The text "123" is for the human user; the fact that this text is something called "foo" is for the computer. When the document is rendered, the human user will see "123" here. Maybe computer will enhance something or maybe it will just use it as index or reference, whatever.

Most people who don't like XML seem to only encounter it in config files. In config files there's normally no content that needs to be there for the end users, so all data can happily go into attributes. The text content starts to matter when we deal with natural language texts.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#232

Post by crdoconnor »

ZenoArrow wrote: post #50
wtbob wrote: post #42

Earlier quoted context omitted.

> I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. On the contrary, I think that XML's bad reputation comes from the fact that it is so incredibly verbose . Also, the whole child/attribute dichotomy is a huge, huge mistake. I've been recently dealing with the XDG Menu Specification, and it contains a child/attribute design failure, one which would ha…

> "The best human-readable data transfer format is probably canonical S-expressions" I personally think TOML is a bit more readable... https://github.com/toml-lang/toml

YAML is more readable than TOML though.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#233

Post by Mikhail_Edoshin »

lmm wrote: post #224
erlehmann_ wrote: post #211

Earlier quoted context omitted.

XML without namespaces does not exist. If it existed, how would you differentiate between title and link elements in Atom and title and link elements in XHTML? They have the same element names, but do not have the same meaning and therefore must be processed differently. Namespaces ensure that any XML processor can know the language of each part of the input. Namespaces actually are the general mechanism with which y…

> XML without namespaces does not exist. If it existed, how would you differentiate between title and link elements in Atom and title and link elements in XHTML? By where it is in the structure. The document is a tree where each element has well-defined context; there should never be confusion about whether a particular is part of the feed or part of the content in the feed, because if it's in content it will be insi…

You may have incomplete documents (e.g. documents with conditional sections, very much like XSLT):
Here you'll first process your code part an copy the contents as they are and then process the contents; but in the source document the two languages are interspersed.

Or you may want to extend your text format with, say, literate programming and add code fragments and files. In my homegrown system it's like that:

    
      ...
      ...
My text system already has a notion of captions so there's no need to add my own "literate:caption" here. Yet the other two "literate" elements are new an unique. Also, using a namespace here ensures that I'm sure not to have a clash if the base system adds their own "fragment" or "code" blocks.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#234

Post by barrkel »

nialo wrote: post #127
barrkel wrote: post #32

Earlier quoted context omitted.

The biggest problem with XML is that it's a node labeled tree that makes the schema choice between leaf node and attribute for scalar data almost arbitrary, whereas JSON is an edge labeled tree without the same choice. Most programming languages use edge labeled graphs for in memory data structures, so the semantic distance is lower with JSON.

Can you explain what you mean by JSON being an edge labeled tree in more detail? I don't understand and would really like to.

Graph theory terminology: nodes are connected by edges. When drawn, the edges are the lines, the nodes are the blobs that are connected by lines.

All trees are graphs. Not all graphs are trees; there could be cycles, or children with multiple parents in an arbitrary graph.

In JSON, the nodes are literals: numbers, strings, booleans, arrays, hashes (object constructors). The edges are hash keys (object field names in the constructors).

In XML, the nodes themselves have the names. The edges are implicit in the syntax via containment, and are unlabeled.

In programming languages, generally our values don't have names. Instead, our variables have names, and refer to values; variables can be assigned different values, but the name doesn't change. More physically, if the values are stored on the heap, variables are pointers to values on the heap, and fields of heap objects are further pointers to more values on the heap. Here, variables and fields are edges, and the values are the nodes. Looked at from a graph theory perspective, the in-memory model is an edge labeled graph.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#235

Post by lmm »

Mikhail_Edoshin wrote: post #233
lmm wrote: post #224

Earlier quoted context omitted.

> XML without namespaces does not exist. If it existed, how would you differentiate between title and link elements in Atom and title and link elements in XHTML? By where it is in the structure. The document is a tree where each element has well-defined context; there should never be confusion about whether a particular is part of the feed or part of the content in the feed, because if it's in content it will be insi…

You may have incomplete documents (e.g. documents with conditional sections, very much like XSLT): Here you'll first process your code part an copy the contents as they are and then process the contents; but in the source document the two languages are interspersed. Or you may want to extend your text format with, say, literate programming and add code fragments and files. In my homegrown system it's like that: ... .…

OK, I guess that takes things a level up. I don't like that kind of interspersed style and I don't think incomplete documents should be the same kind of thing as complete ones (e.g. one can't meaningfully validate your first example, because what if the "whatever" is an element that has to be present exactly once). But I can see that if you want to write things this way then namespaces help.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#236

Post by nrser »

flomo wrote: post #118
nrser wrote: post #77

Earlier quoted context omitted.

i think a major problem is that XML kinda looks and feels like HTML (and there was the whole XHTML thing to further confuse), and outputting HTML programmatically (vs string / print / template based) has most been frowned on as overweight and cumbersome. you come from web dev doing HTML like that and you see XML and think "hey, that looks the same, i'll do it in the same way". XML is a programmatic data exchange form…

Outputting JS as templates or printed text was pretty common before every language added a handy toJson method though.

yeah, I guess I sorta missed that... I mean the 'X' in AJAX was for XML... I've def been guilty of outputting "XML" with php tags. by the time we got to JSON there were libs available, or maybe we just wrote our own.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#237

Post by lmm »

erlehmann_ wrote: post #230
lmm wrote: post #224

Earlier quoted context omitted.

> XML without namespaces does not exist. If it existed, how would you differentiate between title and link elements in Atom and title and link elements in XHTML? By where it is in the structure. The document is a tree where each element has well-defined context; there should never be confusion about whether a particular is part of the feed or part of the content in the feed, because if it's in content it will be insi…

> The document is a tree where each element has well-defined context; there should never be confusion about whether a particular is part of the feed or part of the content in the feed, because if it's in content it will be inside the content tag. In this specific case, maybe – but generally, it is not true that you can infer the namespace of an element from context. Also, elements can have multiple attributes with di…

> It is very useful to embed any arbitrary language, as XML processors can preserve the content they do not understand without processing it. My XSLT stylesheet would have no issue with SVG embedded in XHTML, just as your web browser most likely ignores everything about the SVG linked above it can not understand.

Sure, but you can ignore extra attributes in JSON or hypothetical XML-without-namespacing too. I feel like there's an excluded middle here: either the content of a given tag has to be, say, SVG, in which case the validation schema for the outer document could just say (in a structured way) "the content of this tag must be a valid SVG document according to the SVG schema", or the content is some opaque arbitrary XML document, in which case there's no meaningful validation to be done.

Even when working with something like XHTML-with-embedded-SVG, I found myself wishing there was a way to strip the namespaces, run my xpath queries / xslt transformations on the stripped version, and then put the namespaces back; I think I'd've got my actual business tasks done a lot quicker that way.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#238

Post by wtbob »

Mikhail_Edoshin wrote: post #231
wtbob wrote: post #42

Earlier quoted context omitted.

> I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. On the contrary, I think that XML's bad reputation comes from the fact that it is so incredibly verbose . Also, the whole child/attribute dichotomy is a huge, huge mistake. I've been recently dealing with the XDG Menu Specification, and it contains a child/attribute design failure, one which would ha…

The creators of XML were aware that it was verbose; they mention in their design goals that this was the least priority. Child and attribute "dichotomy" is not a mistake. What you mean is that these two samples appear to be equivalent: 123 But they are not equivalent. The first line (with an attribute) is there solely for the computer. When the document is rendered, the human user is not supposed to see anything ther…

> The creators of XML were aware that it was verbose; they mention in their design goals that this was the least priority.

Which seems pretty wasteful.

> Child and attribute "dichotomy" is not a mistake.

It's not for a markup format — as I mentioned, it can make sense there — but, as you mentioned, it doesn't make sense in a config or data file format.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#239

Post by cptskippy »

einhverfr wrote: post #179
cptskippy wrote: post #165

Earlier quoted context omitted.

Oh EDI... you made me shudder.

No experience with ASN.1?

Nope. I ran into EDI when I was doing an integration for a JIT Hub that had to integrate with Hitachi and Seagate inventory systems. It was pretty awful to work with but the protocol was rock solid.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#240

Post by cptskippy »

einhverfr wrote: post #39
cptskippy wrote: post #11

Earlier quoted context omitted.

For one, JSON didn't exist 15 years ago. For another, JSON didn't have validation or schemas 5 years ago.

Even there, the schemas and validation are very lightweight compared to what XML can do. As I usually say, JSON is for relatively free-form, dynamically typed languages, but if one side is uses a statically typed language, XML is probably the better choice.

Hmm... I always tend to use XML for B2B communication or Mine-to-Theirs type RPCs. I use JSON primarily for Client-to-Server communication internally with own applications or for public APIs.
Post reply on HN