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

201–210 of 255 posts

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

#201

Post by lmm »

erlehmann_ wrote: post #188
mikeash wrote: post #182

Earlier quoted context omitted.

If they're all then you're back to square one. JSON solves this with indentation, pretty printing, and using paired symbols that most conpetent editors can automatically balance. This solves the homogeneous case too. Incidentally, XML can benefit from the first two, and many editors balance tags, so you can get the same thing there.

It is rare in real-world XML that elements have children with the same type. Do you have a (non-divitis) example where the tags are all the same?

It happens with any tree structure. E.g. I used to work on a system that managed reinsurance contracts and represented them as trees of contracts.

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

#202

Post by lmm »

erlehmann_ wrote: post #189
wtbob wrote: post #162

Earlier quoted context omitted.

> The second and third examples do not have namespaces. > How would you include an HTML summary, for example? As a text attribute, honestly — which would be necessary in XML as well (you could embed XHTML in XML, but not HTML). And in the general case, embedding one variant of XML inside another, rather than embedding a character-encoded variant of XML inside another, doesn't seem all that useful. How often do transf…

> How often do transforms need to reach all the way in like that? In my experience, almost every time XSLT is used on real-world documents, those are documents with multiple namespaces. XSLT stylesheets themselves are also documents that have multiple namespaces. Example: Atom feeds often contain XHTML content. It is a common problem with RSS that it does not specify if the content of an element is HTML or plain text…

I would be convinced if I saw real-world examples where having namespaces gave an advantage over not having namespaces. I can see the value in specifying whether the content of a given node is XHTML or text. I can at least theoretically see value in allowing nesting XHTML without a layer of escaping. I can't see any non-theoretical way in which namespaces are necessary to accomplish these things.

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

#203

Post by lmm »

wtbob wrote: post #164
PeterisP wrote: post #143

Earlier quoted context omitted.

There is a very big difference - "with JSON one still must check the expected types anyway" is not really true, I can deserialize an arbitrary json and I will know the difference between 123 and "123" even if I don't know what's expected or, alternatively, mixed-type values are expected.

> There is a very big difference - "with JSON one still must check the expected types anyway" is not really true, I can deserialize an arbitrary json and I will know the difference between 123 and "123" even if I don't know what's expected or, alternatively, mixed-type values are expected. You will still need, in your code, to handle both 123 & "123" (or handle one, and error on the other). That's really no different…

> You will still need, in your code, to handle both 123 & "123" (or handle one, and error on the other). That's really no different from, in your code, parsing "123" as an integer, or throwing an error.

It is different because in the latter case you have to write your own code to do it, while in the former your library will handle it for you.

> If one is willing to use a Scheme or Common Lisp reader, of course, then numbers &c. are natively supported, at the expense of more quoting of strings (unless one chooses to use symbols …).

So this format comes in dozens of partially-incompatible variants? Lovely.

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

#204

Post by lmm »

ZenoArrow wrote: post #185
legulere wrote: post #99

Earlier quoted context omitted.

For configuration files, not for data serialisation.

Let's put it like this... what can you express in JSON that you couldn't express in TOML?

I can cleanly parse JSON, serialize it, and be confident I haven't lost anything. That can't be done for a language that allows comments without complicating the AST.

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

#205

Post by lmm »

MichaelMoser123 wrote: post #184
zachrose wrote: post #140

Earlier quoted context omitted.

Taking a stab at this... Let's say we have a dog who has four paws. In XML: In JSON: { "paws": [ { "health": "ok" }, { "health": "ok" }, { "health": "ok" }, { "health": "ok" }, ] } I think what the GP is getting at is that JSON is always describing the relationships between a thing and another thing, rarely the things themselves. In the JSON version, for example, it can be assumed that an object in the "paws" array i…

I don't quite see why you can't do the same with xml; maybe it needs some more typing, but it is expressing the same thing. i thought that the main advantage of json was that it can be used as is (code as data) in javascript, but the problem here of course is that without a parser/validator one can inject tons of malicious code. If you are not on javascript then you can't do without a parser / in memory tree structur…

> I don't quite see why you can't do the same with xml; maybe it needs some more typing, but it is expressing the same thing.

It's not idiomatic though - the dog's paws aren't "healths". The point is that in XML each tag is expected to have a label and be an entity in its own right, whereas in JSON you expect each field to be an attribute.

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

#206

Post by erlehmann_ »

lmm wrote: post #202
erlehmann_ wrote: post #189

Earlier quoted context omitted.

> How often do transforms need to reach all the way in like that? In my experience, almost every time XSLT is used on real-world documents, those are documents with multiple namespaces. XSLT stylesheets themselves are also documents that have multiple namespaces. Example: Atom feeds often contain XHTML content. It is a common problem with RSS that it does not specify if the content of an element is HTML or plain text…

I would be convinced if I saw real-world examples where having namespaces gave an advantage over not having namespaces. I can see the value in specifying whether the content of a given node is XHTML or text. I can at least theoretically see value in allowing nesting XHTML without a layer of escaping. I can't see any non-theoretical way in which namespaces are necessary to accomplish these things.

Example: The XSLT stylesheet for this Atom feed generates a web page for each entry: http://news.dieweltistgarnichtso.net/notes/index.xml In this setup, the Atom XML for each entry is generated from XHTML with XSLT, which makes it possible to automatically include an Atom enclosure element for every XHTML media element. To publish a podcast episode, it is enough to add a post with an or element, as an XSLT stylesheet can “reach into” the XHTML content.

Namespaces are also widely used in SVG, which uses the XLink specification for hyperlinks and can embed XHTML and MathML content. Since SVG can be embedded in (X)HTML, this means you can have an ATOM feed containing XHTML containing MathML and SVG that contains XHTML and all have it displayed correctly.

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

#207

Post by chriswarbo »

SomeCallMeTim wrote: post #125
mwfunk wrote: post #121

Earlier quoted context omitted.

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 bin…

>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 t…

I've always considered YAML to be far too complicated. There are many overlapping/redundant syntax rules for doing the same thing, lots of ways to mess up parsing, etc.

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

#208

Post by lmm »

erlehmann_ wrote: post #153

Discussions about XML and JSON often remind me of this comment on HN: https://news.ycombinator.com/item?id=5702868 Partial quote: > XML can certainly be shorter than JSON and often is, and repeated tags are the best showcase for it: 123456789 321654987 > This turns into this beautiful JSON: [ "users": [ { "id": "abc", "phoneNos": [ { "type": "home", "value": "123456789" }, { "type": "work", "value": "321654987" } ] }…

Not a fair comparison since the JSON case includes the outer list as well. And whenever I've seen the equivalent of this in a real-world XML format it would use a tag to group the phone numbers together.

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

#209

Post by lmm »

erlehmann_ wrote: post #206
lmm wrote: post #202

Earlier quoted context omitted.

I would be convinced if I saw real-world examples where having namespaces gave an advantage over not having namespaces. I can see the value in specifying whether the content of a given node is XHTML or text. I can at least theoretically see value in allowing nesting XHTML without a layer of escaping. I can't see any non-theoretical way in which namespaces are necessary to accomplish these things.

Example: The XSLT stylesheet for this Atom feed generates a web page for each entry: http://news.dieweltistgarnichtso.net/notes/index.xml In this setup, the Atom XML for each entry is generated from XHTML with XSLT, which makes it possible to automatically include an Atom enclosure element for every XHTML media element. To publish a podcast episode, it is enough to add a post with an or element, as an XSLT stylesheet…

> Example: The XSLT stylesheet for this Atom feed generates a web page for each entry: http://news.dieweltistgarnichtso.net/notes/index.xml

> In this setup, the Atom XML for each entry is generated from XHTML with XSLT, which makes it possible to automatically include an Atom enclosure element for every XHTML media element. To publish a podcast episode, it is enough to add a post with an or element.

Sure. Why do you need namespaces to do that? Why couldn't you do it in XML-without-namespaces (or even JSON and some theoretical JSON-transformation-lanugage?)

> Namespaces are also widely used in SVG, which uses the XLink specification for hyperlinks and can embed XHTML and MathML content.

Again, why are namespaces necessary though? Why not just have a tag whose content is specified to be XHTML/MathML ? Wouldn't you want that anyway for the sake of human readability?

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

#210

Post by HelloNurse »

int_handler wrote: post #172
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…

My impression is that the reason why XML is so well-regarded in the enterprise is because these companies are not aware of better alternatives, such as Protocol Buffers [1]. The reason why XML has a bad reputation outside of the enterprise is because it is so incredibly verbose (both the language itself and the code used for working with it), and that all-in-all, it is a sub-optimal solution to a solved problem. To i…

Protocol Buffers are just one of many proprietary serialization libraries. Regardless of technical excellence, Protocol Buffers and competing libraries are automatically much less suitable for actual enterprise use than open standard serialization protocols with multiple interoperable implementations, such as ASN.1. And of course, XML is usually preferable to ASN.1 or the like because it is equally standardized but it has an ample choice of implementations, advanced tools and human readability and writability.
Post reply on HN