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

241–250 of 255 posts

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

#241

Post by cptskippy »

beagle3 wrote: post #46
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.

JSON was defined in April 2001, basically a subset of JavaScript specs from 1999. So, JSON did exist 15 years ago, but not 16 years ago, although you have to go back 20 years if you want your statement to not just be about the name. And yet ... how many of the decisions to use XML go back those 15 years? Hardly any.

JSON may have been created 15 years ago but it wasn't well known or commonly used for a number of years. Yahoo! only started using it in 2005 and Google in 2006. XML had been around and in use for years prior to that and even today has a much richer toolchain.

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

#242

Post by 616c »

CamperBob2 wrote: post #113
616c wrote: post #76

Earlier quoted context omitted.

I think the worst of this is what I call semantic incoherence. I have a system that has things like Blah . Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string? Another favorite: [CDATA[Batchfile.bat]] , while a binary or something else will be "program.exe /argument:f /argument2:x" . By the way, this is an enterprise as it gets: a software tool from a four-letter hardwa…

I have a system that has things like Blah . Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string? You're really asking a different question here: "Why should an integer be used as a task ID?" Storing the task ID as a string may give you options in the future that you wouldn't otherwise have, at a relatively small cost in parsing performance and validation overhead. Most…

I see were you were downvoted, but I happen to see merit with your comment. Again, a lot of people make technical decisions without stepping back and just scanning their choices as non-specialist (in the context of their programming domain) and ask hey, does this make sense?

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

#243

Post by moosingin3space »

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'd say TOML [0] is the best because it can be a very simple key=value structure, but also supports very detailed, nested structures. It has a 1-to-1 correspondence with JSON, but is more friendly for configuration (comments are a huge help!)

[0]: https://github.com/toml-lang/toml

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

#244

Post by edejong »

qwertyuiop924 wrote: post #166
qwertyuiop924 wrote: post #139

Earlier quoted context omitted.

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 )

Yeps, that's basically HATEOS :)

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

#245

Post by SomeCallMeTim »

clockwerx wrote: post #159
SomeCallMeTim wrote: post #129

Earlier quoted context omitted.

>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 I don't understand is why anyone thought using XML that way was a good idea, and why it still is popular in the enterprise. Bad habits are hard to break, I guess. Namespaces, which then gives you easy answers for Internationalisation (xml:lang), a subject-predicate-object data structure (RDF), which can lead on to logical meaning/modelling of data (RDFS/OWL), which then lets you look at harder questions like t…

Sounds great in theory. In practice it doesn't seem nearly as carefully implemented, and/or XML is used where it's actually not needed.

XML is designed to be a markup language. The fact that it has all of these other things bolted on doesn't actually make it a good generic data interchange format.

For things like RDF, maybe it's the best option we have, but that's not because XML is great, it's because XML was used in the only standardized option.

Looking at an example of xml:lang:

    
    
     
      
Texte en français.

      Texte en québécquois.

      Second text in English.

     
     
Text in English.
...this is a nightmare. If I want to translate a document, the last thing I want to do is embed each translation inline like that. Almost certainly the best response is to "fork" the document at the highest level and include separate language versions of the document; otherwise, if you have 20 translations of the document, you need 20x the text in the document than any one reader will need.

Yes, XML gives you that particular hammer. But using XML results in a lot of sore thumbs.

Schema validation is nice to be sure. I'm using JSON Schema Validation myself [1] to verify incoming JSON, and I'm automatically generating those schemas from the TypeScript data structure specifications [2]. This is particularly good for a JavaScript language target, of course, but I find XML and XPath to be ugly or painfully slow in every language I've used it from, while JSON just has a better impedance match to data storage and interchange.

[1] http://json-schema.org/

[2] https://github.com/YousefED/typescript-json-schema

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

#246

Post by edejong »

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…

> Firstly, I'm pretty sure REST implies a message-passing architecture. Correct me if I'm wrong.

It absolutely is, but afaik (correct me if I'm wrong here) it implies an origin. It relies completely on addressable and available resources. It relies on exactly-once semantics (POST) and round-trips. Message passing for me is more like the actor model: ephemeral information, at most-once delivery, references to computers (actors), not data, and most important: the message is centric, not the end-point.

Perhaps I'm understanding all of this completely wrong, I'm honest here, but the actor model for me means 'message passing orientation' and RESTful to me means 'resource orientation'.

> And you would ask for example.com//static/X57pqr32.

I implemented more or less the same scheme in a message centric application for crypto. Larger objects such as photos and videos were encrypted and placed in a central storage (later design phase included DHT implementation). The receiver could decrypt the message at a later time, whenever the photo was visible in the app/webpage. The central server, however, was non the wiser, as all data was encrypted and without semantic information. Here it is interesting to note that, even though we use references (URIs), the resource is not identifiable, except for its SHA hash signature. There was no sense in saying: https://kanta-messenger.com/photos/1234abcd since there is no knowledge of 'photo' or 'video'. However, there is still representable state transfer (REST) going on, without any of the semantics.

> . Now all we need to do is build something to put JSONP in the ground...

Agreed

> By the way, did you look at Cap'n Proto and MessagePack?

We had two phases (since it takes quite a lot of time to research each data-exchange protocol). In the first phase, we evaluated on a couple of core criteria: Language support (Scala, Java, Python), no long-standing github issues, more than one core commiter. We reduced that to three protocols: protobuf, Flatbuffers and Apache Avro. To most of our surprise, the last one won. Why? Various reasons, one of them being the possibility to do reflection and search within encoded messages for which the receiver does not have a schema. For example, you might want to create a router which only routes messages which contain a certain header. Another is archiving: since the schema is always included, it is possible to decode messages years after they have been stored somewhere. A third one is forward- and backward-compatibility. All of them were close wins (4 vs. 5 stars), but it brought us to Apache Avro. Looking back on that decision, it was a good one. Many within the company are happy with the choice.

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

#247

Post by int_handler »

HelloNurse wrote: post #210
int_handler wrote: post #172

Earlier quoted context omitted.

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

Protocol Buffers is not proprietary. It is open source under the BSD license. Here is the source code: github.com/google/protobuf. It is very much an open protocol, and anyone is free to write their own implementation of it. It is just a standards-based protocol.

If your organization values the existence of a standard over technical excellence, then there is no use in convincing you. Otherwise, in terms of ease of use, performance, tooling, and human readability and writability, Protocol Buffers is superior to XML-based protocols (since the API for converting between the binary and text formats is extremely simple to use).

As a fun fact, if you really wanted to use XML as a wire format, you could even write an XmlFormat ser/de for Protocol Buffers, similar to the JsonFormat that is already provided, but then it would defeat one of the main purposes of using Protocol Buffers in the first place because you would replace an extremely performant wire format with an extremely sub-optimal one.

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

#248

Post by CamperBob2 »

616c wrote: post #242
CamperBob2 wrote: post #113

Earlier quoted context omitted.

I have a system that has things like Blah . Why is the ID, clearly always an integer in every sample of hundreds I see, represented as a string? You're really asking a different question here: "Why should an integer be used as a task ID?" Storing the task ID as a string may give you options in the future that you wouldn't otherwise have, at a relatively small cost in parsing performance and validation overhead. Most…

I see were you were downvoted, but I happen to see merit with your comment. Again, a lot of people make technical decisions without stepping back and just scanning their choices as non-specialist (in the context of their programming domain) and ask hey, does this make sense?

Technically all attributes are supposed to be surrounded by quotes regardless of how they're interpreted. That renders the premise of my whole comment invalid, to be "technically correct," so the people downvoting may have had that in mind.

Still, there are plenty of XML applications that leave out the quotes on numeric attributes. My point was really that they're not doing themselves any favors by abusing the spec that way. A text-based markup language is a great example of how premature optimization is unhelpful most of the time.

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

#249

Post by j4_james »

wtbob wrote: post #115
JoshTriplett wrote: post #108

Earlier quoted context omitted.

> 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. Those two factors run counter to each other. Attributes decrease verbosity, compared to child elements. I agree, though. A few changes would make XML closer to ideal: eliminate attributes and eliminate the name in closing tags ( value ), which makes child elem…

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

> I particularly like how URIs are sometimes encoded as attributes and sometimes as child text elements.

I think the distinction here is that the one is an identifier which is not intended to be dereferencable, and the other is a link to a resource which has to be retrievable. In the good old days the id would most likely have been a URN and the link a URL, but that distinction was being discouraged in favour of the more general URI term at the time the Atom spec was developed. [1]

So while they're syntactically both URIs (well technically IRIs), they're functionally quite different. It may be debatable whether that's a good enough reason for the one to be an element value and the other an attribute value, but I don't think that decision was obviously wrong.

[1] https://tools.ietf.org/html/rfc3986#section-1.1.3

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

#250

Post by qwertyuiop924 »

edejong wrote: post #246
qwertyuiop924 wrote: post #139

Earlier quoted context omitted.

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…

> Firstly, I'm pretty sure REST implies a message-passing architecture. Correct me if I'm wrong. It absolutely is, but afaik (correct me if I'm wrong here) it implies an origin. It relies completely on addressable and available resources. It relies on exactly-once semantics (POST) and round-trips. Message passing for me is more like the actor model: ephemeral information, at most-once delivery, references to computer…

>All of them were close wins (4 vs. 5 stars), but it brought us to Apache Avro. Looking back on that decision, it was a good one. Many within the company are happy with the choice.

Neat, I may check it out.

>It absolutely is, but afaik (correct me if I'm wrong here) it implies an origin. It relies completely on addressable and available resources. It relies on exactly-once semantics (POST) and round-trips. Message passing for me is more like the actor model: ephemeral information, at most-once delivery, references to computers (actors), not data, and most important: the message is centric, not the end-point.

I mean, that IS a valid way to think about it. I think about it like this:

when you're using a REST API, you are sending a message to an application. That application is defined in part by your endpoint: The server, and the path to the app. The rest of your message (params, method, remaining path) is your message. Some applications map the messages you send them onto a sort of virtual filesystem, which may or may not correspond to a real one. This appears in webservers, and many APIs. For these, messages you send primarily consist of paths. Others treat their messages more as procedure calls, and use more params. Both are messages, just as sure as

  cat /proc/sys/net/ipv4/ip_forward
and

  sysctl net.inet.ip.forwarding
even though one uses a filesystem model, and the other uses a command.

But your model of REST, while less linked to message passing, has much less cognitive load.

There's something wrong with me.

Actually, it's funny we're discussing message passing, because I've been working on an app that uses message passing between pre-emptive co-routines, and kinda-sorta unidirectional data flow heavily. Of course, at 2 coroutines per connection, it won't scale. Thankfully, it won't have to.

I hope.

Post reply on HN