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

91–100 of 255 posts

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

#91

Post by nitrogen »

kyllo wrote: post #82
chiph wrote: post #3

Back in the early days of XML, Internet Explorer would insert "+" characters to fold nested sections of XML. And was the default program to open .xml files. Guess what showed up in the documents I got from an integration partner?

I once got an XML file from an integration partner where the whole thing was XML escaped (all the tags looked like <node>value</node>) because they had embedded it within an outer "envelope" XML file. They saw nothing wrong with this and argued when I questioned it. I wonder how they were planning to express escape sequences within the inner XML document that was already escaped...

It's ugly of course, but a parser should have no problem with & or <. It can go arbitrarily deep.

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

#92

Post by ams6110 »

616c wrote: post #84
ams6110 wrote: post #81

Earlier quoted context omitted.

> Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string Becase XML is a text-based markup. If you truly want binary data you need to encode it and use CDATA sections.

That was not quite my point. Why pretend it is a string at all? 3 I should have been more clear. Sometimes you have these argument type deals where I would at least hope for or the monstrosity above (I assume ID=3 is not valid in hindsight, I am getting tired just writing this all on the second pass even!). And I see all different variations in the same XML file! There is no logical consistency, not even in the same…

XML as a config file format was a disaster in every example I ever encountered. Config files are supposed to be editable by humans using editors, and most that I saw were too complex for that. In particular the NeXT/Apple property file formats are horrible abuses of XML.

As a format to represent structured data, it could be fine as long as you were pragmatic about it. In the case of you either assumed that "id" was always an integer or you validated it with a schema declaration, which quickly got hairy.

In practice I never validated XML beyond it being well-formed (which was provided by default in any parser) and never had any real problems.

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

#93

Post by chiph »

616c wrote: post #84
ams6110 wrote: post #81

Earlier quoted context omitted.

> Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string Becase XML is a text-based markup. If you truly want binary data you need to encode it and use CDATA sections.

That was not quite my point. Why pretend it is a string at all? 3 I should have been more clear. Sometimes you have these argument type deals where I would at least hope for or the monstrosity above (I assume ID=3 is not valid in hindsight, I am getting tired just writing this all on the second pass even!). And I see all different variations in the same XML file! There is no logical consistency, not even in the same…

Oh, this is the difference between attribute-oriented XML, element-oriented XML, and whatever-the-hell-we-feel-like-oriented XML. Publishers should pick one of the first two and be consistent about it.

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

#94

Post by yuhong »

legulere wrote: post #90

There's really no reason to use UTF-16 but compatibility with older software (which is usually broken when handling surrogate pairs). It's an atavism from times when all unicode codepoints fitted into 16 bit.

I think that one boils to basically back in 1990, ISO 10646 wanted 32-bit characters but had no software folks on that committee, while the Unicode people was basically software folks but thought that 16-bit was enough (this dates back to the original Unicode proposal from 1988). UTF-8 was only created in 1992, after the software folks rejected the original DIS 10646 in mid-1991.

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

#95

Post by thangalin »

616c wrote: post #84
ams6110 wrote: post #81

Earlier quoted context omitted.

> Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string Becase XML is a text-based markup. If you truly want binary data you need to encode it and use CDATA sections.

That was not quite my point. Why pretend it is a string at all? 3 I should have been more clear. Sometimes you have these argument type deals where I would at least hope for or the monstrosity above (I assume ID=3 is not valid in hindsight, I am getting tired just writing this all on the second pass even!). And I see all different variations in the same XML file! There is no logical consistency, not even in the same…

What takes fewer lines of code to parse?
Or accepting both:
How would you specify an empty value for mandatory attributes?

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

#96

Post by oceanswave »

stesch wrote: post #56
oceanswave wrote: post #20

Earlier quoted context omitted.

The way your comment comes across is a bit irritating. Not understanding the underlying codebase and classifying based on an attenuated knowledge of a topic promotes one to the 'bozo' status more quickly than not. Many systems use text-template based feeds, examples are Shopify, Salesforce, Wordpress, and more. Are these systems fundamentally broken purely because of this approach? Probably not. In your case, are the…

You mention typical PHP projects written by people who think they know better than the likes of Tim Bray. PHP, the language that made short tags a configuration option because they wanted to mix program code with XML. PHP, the language with a lot of different escape functions because they didn't get it right the first time.

I also mentioned projects written in Ruby and Java, but that's ok. VB.Net also has XML Literals. Ha ha.

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

#97

Post by ams6110 »

chiph wrote: post #93
616c wrote: post #84

Earlier quoted context omitted.

That was not quite my point. Why pretend it is a string at all? 3 I should have been more clear. Sometimes you have these argument type deals where I would at least hope for or the monstrosity above (I assume ID=3 is not valid in hindsight, I am getting tired just writing this all on the second pass even!). And I see all different variations in the same XML file! There is no logical consistency, not even in the same…

Oh, this is the difference between attribute-oriented XML, element-oriented XML, and whatever-the-hell-we-feel-like-oriented XML. Publishers should pick one of the first two and be consistent about it.

Agree. Practical/pragmatic use of XML as a data format requires consistency.

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

#98

Post by trav4225 »

Cpoll wrote: post #45
chrisseaton wrote: post #31

Earlier quoted context omitted.

What do you think JAVA stands for? It's not an abbreviation. It's the name of an island and it's just 'Java'.

It's more accurate to say that it's named for the coffee beans that come from said island.

It's even more accurate to say that it's named for the coffee made from the coffee beans that come from said island. ;-)

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

#99

Post by legulere »

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

For configuration files, not for data serialisation.

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

#100

Post by 0xcde4c3db »

cillian64 wrote: post #61
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…

I think the benefit of a serialization library is going to depend on how complex and dynamic your actual output is. I've done XML-by-printing, but in that case the XML elements were fixed scaffolding with no relation to our internal object hierarchy (A containing array of B containing array of C containing array of D, always, regardless of how our application changed). It was also on an embedded system for which adding libraries was kind of painful.
Post reply on HN