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

161–170 of 255 posts

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

#161

Post by bane »

voltagex_ wrote: post #160
bane wrote: post #110

My "favorite" XML formats are the one that are just some kind of weird meta-format and don't really use any of the XML features: blah blah this is the attribute value ... And yes, these types of abominations are everywhere. The only way to avoid being called a Bozo when producing XML is to either a) ensure that humans never had to see this craziness b) don't use XML XML as a config file format, in particular, is prob…

How would you write that example while taking advantage of the XML features you're talking about?

I think what you might be asking is "what would more idiomatic XML look like?" And that's a fair question for people who haven't spent lots of time working with XML.

First off, I think attributes are evil. In theory, they're good, but nobody knows how to use them, so they shouldn't ever be part of your XML. They're simply elements with cardinality of 1.

The format would probably be better as:

   
      
         1
         
            abc
            blah blah
         
         this is the attribute value
      
      
      ...
This is a completely valid XML language, is much more clearer, less verbose, doesn't overload element names, doesn't abuse attributes, etc. etc.

One important thing that most people don't get about XML is that XML is a specification for describing data-interchange formats. XML isn't a format, or a language. The result of following the XML spec is an "XML format".

If somebody asks what format some data format is in, it's more appropriate to say "it's in an XML" rather than "it's in XML".

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

#162

Post by wtbob »

erlehmann_ wrote: post #149
wtbob wrote: post #115

Earlier quoted context omitted.

> A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags ( value ), which makes child elements much less verbose, and reduces the need for attributes. Then just change ' ' to '(tagname,' and ' ' to ')' and you'll have S-expressions. Consider this: (feed (version 1) (title "Example Feed") (link http://example.org/) (updated "2003-12-13T18:30:02Z") (author (name "John…

The second and third examples do not have namespaces. How would you include an HTML summary, for example?

> 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 transforms need to reach all the way in like that?

I guess it's cool if it's possible, which is why I like S-expressions all the way down. But I don't think it's all that useful, as opposed to neat.

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

#163

Post by wtbob »

zyxley wrote: post #144
wtbob wrote: post #117

Earlier quoted context omitted.

> S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. Take a look at https://news.ycombinator.com/item?id=12198581 ; I think it demonstrates how readable one dialect of S-expressions can be. > I also can't see how they map easily into datastructures of imperative programming languages JSON consists of numbers, strings, booleans, objects and arr…

You could do make it more like S-expressions in JS if you really wanted. {object: [ {id: "1234"}, {isEnabled: "true"}, {props: ["abc", "123", "false"]}]} Not quite the same, but nothing keeps you from parsing an array of key/value pairs instead of a hash.

You may not leave JSON object properties unquoted, so it'd have to read:

    {"object": [
      {"id": "1234"},
      {"isEnabled": "true"},
      {"props": ["abc", "123", "false"]}]}
So you have extraneous quotes, extraneous semicolons, extraneous commas, plus the parsing code is complicated by having to handle all of that rather than atoms & lists (that's not a strong reason, since parsing code is written once and used millions of times).

I really, really don't get the visceral opposition to S-expressions. From my perspective they're both better & simpler.

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

#164

Post by wtbob »

PeterisP wrote: post #143
wtbob wrote: post #117

Earlier quoted context omitted.

> S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp. Take a look at https://news.ycombinator.com/item?id=12198581 ; I think it demonstrates how readable one dialect of S-expressions can be. > I also can't see how they map easily into datastructures of imperative programming languages JSON consists of numbers, strings, booleans, objects and arr…

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 from, in your code, parsing "123" as an integer, or throwing an error.

In JSON one must check that every value is the type one expects, or throw an error. With canonical S-expressions, one must parse that every value is the type one expects, or throw an error. There's really no difference.

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 …).

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

#165

Post by cptskippy »

einhverfr wrote: post #34
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…

XML is very often the least bad format (compared with ASN.1, JSON, X12 EDI, CSV, and other interchange formats), particularly when dealing with statically typed languages. XML is a horrid chimera of SGML but at least it is both human readable, subject to machine validation, and gets the job done.

Oh EDI... you made me shudder.

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

#166

Post by qwertyuiop924 »

qwertyuiop924 wrote: post #139
edejong wrote: post #114

Earlier quoted context omitted.

wrt the XProc pipelining: it's been some time, but I recall various possible transforming and matching steps, such as a conditional stream, transformers, reduction steps of multiple streams and others. This could then be combined with XPath, XQuery, XSLT and even SOAP requests. The problem of XProc was similar to the rest of the XML era: it required too much of the implementer to understand. Also, good programmer too…

Okay. Cool. I wasn't just trying to flame when I wrote: Talking to people who have different ideas and use different stacks is a good idea, and it teaches you things you didn't know before. And learning about stuff is why I use HN in the first place :-). >The problem of XProc was similar to the rest of the XML era: it required too much of the implementer to understand. Also, good programmer tooling, such as graph edi…

By the way, a good example of the multiple-trip RESTful API I described is XKCD's JSON API (http://xkcd.com/info.0.json)

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

#167

Post by cptskippy »

SomeCallMeTim wrote: post #129
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…

>well regarded in the enterprise I think this alone should be enough to cast doubt on it, based on my (albeit limited) interactions with "enterprise" software. >I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. What, like JavaScript? I've had to read and write XML packets from a Node app to work with (surprise!) an enterprise app. I had probably 20 ch…

> What, like JavaScript?

No, JavaScript is not what I'd consider an enterprise language. I'm talking about C++, C#, VB.NET, Java, and LotusScript. Enterprise languages and enterprise applications (e.g. Siebel) have no problem talking to each other via SOAP/XML and they all produce WSDLs that are easily consumed by one another.

When using something like C# or Java you can easily import a WSDL from another application and the toolchain will automatically generate all of objects defined and properly serialize/deserialize XML into those objects. There's no need to write parsers or use sockets/webclients to talk SOAP.

Newer backend languages and frameworks (e.g. RoR, NodeJS, etc) don't have these mature and robust toolchains for XML/SOAP.

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

#168

Post by QuercusMax »

DougN7 wrote: post #63
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.

Pretty much any "real" serialization format should handle that situation fine. Protobuf, JSON, YAML, Thrift, heck, even Java serialization can handle that, provided you set a serialVersionUID.

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

#169

Post by DiabloD3 »

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…

And instead of Protobufs, Cap'n Proto [1], which was started by one of the principal author behind Protobufs, to fix all the flaws in Protobufs.

[1] https://capnproto.org/

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

#170

Post by int_handler »

mwfunk wrote: post #121
bane wrote: post #110

My "favorite" XML formats are the one that are just some kind of weird meta-format and don't really use any of the XML features: blah blah this is the attribute value ... And yes, these types of abominations are everywhere. The only way to avoid being called a Bozo when producing XML is to either a) ensure that humans never had to see this craziness b) don't use XML XML as a config file format, in particular, is prob…

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…

There are plenty, especially in the Java and .NET worlds. To name a few:

* Ant/Ivy * Maven * MSBuild * NuGet package configs

Post reply on HN