How to Avoid Being Called a Bozo When Producing XML (2005) • Hacker News Board

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

#61

Post by cillian64 » Sun, Jul 31, 2016, 4:49 PM UTC

jroseattle wrote: post #14

> Don’t print > Use an isolated serializer Some old reference material (XML isn't as common as JSON anymore), but still worthwhile learning: don't output data formats directly. Directly = echo, print, printf,println...whatever your syntax suggests. I see this happen a lot with my junior engineers, and I have this same conversation with them. Prefer to use data serializers that encapsulate all the syntactical rules th…

Surely it depends where your output is going? Print and friends are ideal for producing human-readable output, especially when it is temporary, for monitoring or debugging. And they are awful for producing stable machine-readable output which you might want to store.

If I'm trying to output straight to a user sitting in front of a terminal, they are going to be very unhappy if I output XML at them. And if my program only outputs machine-readable and requires another layer to turn it into something human-readable, that seems overcomplicated for most applications.

Have I missed the point, or is this advice intended for more specific scenarios than I imagined?

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

#62

Post by edejong » Sun, Jul 31, 2016, 4:54 PM UTC

beagle3 wrote: post #41

edejong wrote: post #17

Earlier quoted context omitted.

I'll add some more reasons to the flamebait: - JSON doesn't have namespaces, making integration of different data-sources quite hard. - XML allows me to do versioning within documents. - An extremely large corpus of well-tested libraries are available. - As opposed to JSON, XML and accompanying standards (XSLT, XML Schema, XPath, XQuery) are extremely well documented. - XML validation, parsing and processing can happ…

> - JSON doesn't have namespaces, making integration of different data-sources quite hard. The only reason anyone would ever say that is ... that they have used XML (or SGML) and are subscribed to that mindset. Every toplevel JSON document is a valid value in any other JSON document. That's how easy it is to integrate. The only reason that XML/SGML needs namespaces in the first place is that the schema dictates what…

I've never really subscribed to the mindset of XML for it has many disadvantages (the verbosity, the complexity of DTD, the tendency for documents which are too large). However, I do subscribe to namespaces, since it allows global referencing of names. I also do subscribe to formal grammars, mature standards, and good documentation. FYI, I've designed streaming JSON based secure messaging systems, did binary-only schema's for speed, and for simple tasks I just implement JSON+REST, since everyone nowadays come to expect it. It's just that I think XML got an undeserved bad reputation and many of the 'good parts' have been forgotten.

With regard to namespaces, when designing standards, it is very useful to separate one 'person' definition from another, since they might not have the same semantics. This allows us to connect, say, 'com.facebook:Person' with 'com.google:Person' with a global equivalence relation. It allows us to specify bridges between standards.

I don't really subscribe to the 'it is a valid value in another JSON document'. It is only valid when it can be interpreted by a receiving program (otherwise it is data, not information). The namespaces are not there for validation (alone), they are there for interpretation.

With versioning, I meant schema versioning. Admittedly, not a great solution, but at least it allows a receiving party to know which parts can safely be interpreted.

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

#63

Post by DougN7 » Sun, Jul 31, 2016, 5:00 PM UTC

Nuffinatall wrote: post #53

Compared to the problems when dealing with 'delimited text', XML is great. Also it's flexible where you can specify properties as attributes or child nodes, depending on wildcard specifications. So I have dealt with lots of edge-case XML situations, but the solutions are always straight forward. Also it helps to have a client vs. trying to parse out raw XML, which means programming and scripting sometimes relies on p…

Handling scope creep is my favorite feature. With XML, it's easy to deserialize even if an expected element is not there, or if there is an extra one you're not expecting, at least that's been my experience. I haven't done much JSON but I'm not sure how that would work with it.

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

#64

Post by djur » Sun, Jul 31, 2016, 5:09 PM UTC

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…

Ruby has had an included XML library since before Rails was released. soap4r is older than Rails too. I wrote my share of clients for SOAP services back then. soap4r wasn't fun to use but it mostly worked. If the service was really simple (a single call and response, for instance) it was sometimes more expedient to put together the request yourself.

When Savon came out 6-7 years ago it was a huge relief. Luckily, by that point, I was seeing a lot less SOAP. But even with Savon, the experience was only lifted to "not awful", never to "wow, I'm glad they used SOAP, this is so easy."

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

#65

Post by edejong » Sun, Jul 31, 2016, 5:14 PM UTC

qwertyuiop924 wrote: post #29

edejong wrote: post #17

Earlier quoted context omitted.

I'll add some more reasons to the flamebait: - JSON doesn't have namespaces, making integration of different data-sources quite hard. - XML allows me to do versioning within documents. - An extremely large corpus of well-tested libraries are available. - As opposed to JSON, XML and accompanying standards (XSLT, XML Schema, XPath, XQuery) are extremely well documented. - XML validation, parsing and processing can happ…

All right, I'll bite: >JSON doesn't have namespaces, making integration of different data-sources quite hard. Yeah, and how often do you merge two data formats like that into one data format in a way that doesn't require massive transformations anyway? >XML allows me to do versioning within documents Well, that's fantastic. Because XML is designed for DOCUMENTS. But JSON is designed as a wire protocol, and a data exc…

Alright, in the flamebait fashion, I'll bite back :)

> Yeah, and how often do you merge two data formats like that into one data format in a way that doesn't require massive transformations anyway?

Actually, quite a lot in the past! Back in 2009 I did some XProc pipelining of messages. These pipelines were a bit like reactive streams, which were (mostly) agnostic of the contents. This allowed me to combine, dissect and route streams of data in an intuitive way. Maybe you can compare it with mapping over a collection: you don't care what's inside, but you want to preserve the contents. XProc was kind of a functional programming + reactive approach to data processing. Pretty cool and ahead of its time, if you ask me.

> But JSON is designed as a wire protocol

Reference, please? Even if I subscribe to one definition of 'wire protocol' on the internet (there are many), I don't think it creates a meaningful distinction between XML and JSON.

> JSON parsing is so simple

Actually, it is, and it isn't. Yes, there are very few primitives (strings, booleans, numbers, arrays, objects), but this also causes important limitations. For example, it is rather cumbersome and unspecified to transfer binary data in a JSON document (base64 encoding). Another thing: how easy is it to parse a streaming JSON document in Javascript?

> The grammar and semantics are on the front page of the site.

Admittedly, that's a lot easier than, say: https://www.w3.org/TR/xml11/ These guys really took it too far...

> That's actually kinda cool.

That's what I thought too when I first heard about it :)

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

#66

Post by kccqzy » Sun, Jul 31, 2016, 5:29 PM UTC

mbrock wrote: post #59

moron4hire wrote: post #51

Earlier quoted context omitted.

> For me the only thing that JSON got better is that JSON is directly mapped to commonly used data structures: arrays and maps. This is nice, but it's also kind of a pain, as it makes you have to stop and think about which structured data elements it's capable of supporting and which you have to send your own metadata through the wire and then reconstruct on your own. For example: Dates. Which is a shame. If there is…

The XML tag style is much, much easier to work with when you're dealing with markup. And XML's purpose is to be an Extensible Markup Language. It's way more appropriate than JSON or S-expressions for that. (Do you prefer to write HTML documents as S-expressions?)

Yes. With good tooling (such as Emacs), markup is much more pleasant to write in S-expressions than XML.

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

#67

Post by dang » Sun, Jul 31, 2016, 5:37 PM UTC

bibinou wrote: post #15

(2005)

Yes. Added.

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

#68

Post by nialo » Sun, Jul 31, 2016, 5:41 PM UTC

Cozumel wrote: post #4

The sheer amount of sites that produce badly formed RSS feeds is staggering, the whole point of a feed is to make your content accessible to everyone, a bit like meta-tags. Why have it if you're not going to at least implement it properly?

I recently wrote a first pass at an RSS feed parser for podcasts, but couldn't find examples of interestingly malformed podcast feeds to test against. Do you have examples of sites with badly formed RSS feeds?

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

#69

Post by [deleted] » Sun, Jul 31, 2016, 5:44 PM UTC

edejong wrote: post #65

qwertyuiop924 wrote: post #29

Earlier quoted context omitted.

All right, I'll bite: >JSON doesn't have namespaces, making integration of different data-sources quite hard. Yeah, and how often do you merge two data formats like that into one data format in a way that doesn't require massive transformations anyway? >XML allows me to do versioning within documents Well, that's fantastic. Because XML is designed for DOCUMENTS. But JSON is designed as a wire protocol, and a data exc…

Alright, in the flamebait fashion, I'll bite back :) > Yeah, and how often do you merge two data formats like that into one data format in a way that doesn't require massive transformations anyway? Actually, quite a lot in the past! Back in 2009 I did some XProc pipelining of messages. These pipelines were a bit like reactive streams, which were (mostly) agnostic of the contents. This allowed me to combine, dissect a…

[deleted]

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

#70

Post by saurik » Sun, Jul 31, 2016, 5:44 PM UTC

djur wrote: post #64

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…

Ruby has had an included XML library since before Rails was released. soap4r is older than Rails too. I wrote my share of clients for SOAP services back then. soap4r wasn't fun to use but it mostly worked. If the service was really simple (a single call and response, for instance) it was sometimes more expedient to put together the request yourself. When Savon came out 6-7 years ago it was a huge relief. Luckily, by…

My experience with early Ruby XML parsers is that they were all "how hard can this be?" hacks someone did over a weekend by people who didn't really use XML or understand the ecosystem of specifiations and thereby barely worked and often didn't support fundamental things like namespaces correctly. It took away everything which made XML powerful and left you with something that was often even finicky.