I often have the feeling that XML would have been much better if it had been more restricted. E.g. trash out namespaces, maybe attributes and put words into explicit rules.
I think JSON went too far into the "restricted" direction, but YAML is a great format.
In theory XML was a great idea. Much better than using cryptic EDI that everyone went back to when the XML experiment fail. I don't know about you but I would much rather use XML for this kind of thing then some Legacy format from the seventies like EDI is. My job uses a lot of EDI for health insurance stuff (834) and there isn't a day I don't wish it was using XML instead.
Used appropriately and sensibly, with a decent level of automatic code generators, it can make interplatform communication far more straightforward to maintain than proprietary bespoke interfaces -- but it can be so easy to succumb to bloat. Because of its ease of understanding, I use it routinely for configuration info, particularly as we have our own packages to read and parse them into our apps in a standard manner.
As I say, used appropriately and sensibly. Same applies to everything, I suppose. I'm prepared to bet that the person who wrote this XML also wrote some appallingly rubbish code to process it. One would be tempted to suggest it's been COBOLed together ...
For bonus, I suppose that the order of the XML-tags have to be strictly followed, otherwise the mainframe's parsing will fail miserably (or end up with wrong values).
Concerning DocMonster's complaint: You're obviously talking about X.12 and not one of the (a little bit better readable) formats like EDIFACT. I think that X.12 might be replaced by EDIFACT in the mid-future since the ASC is now demanding 150$ per years per user of the format (not the software provider shipping the format in their product). This only applies to newer versions of X.12 but still. EDIFACT is free and mostly also included with products that support X.12.
You might prefer to use various hyphens throughout your system. But if system a uses '-' and system b uses ':' - and the hyphen does nothing but seperate longditute and latitude; why are you transmitting the hyphen from a to b? The other option is to just send lat and lon, and let system a use the hyphen it's set up to use and system b use the hyphen it prefers.
"...I'm prepared to bet that the person who wrote this XML also wrote some appallingly rubbish code to process it." More likely to be the committee with plenty of enterprisey requirement documents. And the code is likely very enterprisey also, by a large team with plenty of coding standards.
only byte buffers with platform- compiler- and architecture-dependent alignments!
only byte buffers with platform<hyphen> compiler<hyphen> and architecture<hyphen>dependent alignments!<p>
A number of companies have implemented XML representations of the X12 documents. I'd rather work with the X12 versions any day. The XML is no less cryptic and far more bloated, which starts to matter a lot when dealing with batches with thousands of transactions.
To my eye, this looks like it was probably generated. Someone was given the job of taking a system that produced flat-file output in a variety of similar formats and adapting it to XML - so they wrote something that parsed COBOL records or whatever the source was, and generated XML schemas. Ugly, but not particularly bad by the standards of this site...
Meh. A requirement in the schema that the hyphen element has to be there is also a promise to the consumer of the xml that the hyphen element will always be there.
But yes - it makes no sense to transport static noise in a data format. That is, a hyphen is simply something that in a text file does the job that the syntax does in an XML file. It's metadata, not data, and shouldn't have been put in the data transfer schema.
The underlying bug is that it doesn't belong in a database table, either, for the same reason.
If you have an standards compliant XML Schema then there is a very good chance that you have a code generator that can build you an object model to represent that schema and you have a parser that can parse the XML into that object model. No decent professional programmer would go anywhere near the schema themselves beyond using it to generate objects to work against. The fact that the schema seems to have some overly complex irrelevant parts doesn't matter if those parts are standards compliant. None of it is obviously dumb: if the original schema was generated by a tool then no-one has lost any time on it whatsoever. In fact in the real world programmers who work on corporate codebases quite like XML and XML Schemas because of how well they are supported and the toolsets that are available for working with them.
I've spent quite a bit of time last year working on interfacing with US DoS visitor exchange API. XML based.
The documentation was horrible, some elements were marked as optional, but became required based on a presence of other element. Lots of stuff was misspelled, hardly any examples to be found. It was just me editing XML file and sending a CURL request until it got accepted. Took a while.
My newb fubar moment was when I've realised that the sequences have been used all over the place. Can't see why as the order of the data seemed widely irrelevant in essentially a tree of key value pairs. Still, the schemas proved to be only way to actually see what data EXACTLY needs to go where as again, documentation was spotty at best.
Greatest thing though? Due to various agreements we've interfaced with the API in two ways - first was direct connection, the other was through external partner who required JSON file which then they've converted to XML to be sent through. Oh, and they had their very own set of rules for JSON data so values we were sending were valid if they were put into XML, but opposite wasn't always true.
That was a fun month...
In my experience "big heavyweight enterprise stuff" is generally pretty solid, reliable and helps productivity. Cool technologies are generally just a disappointing time sink. But that's just my opinion. Loved the idea of .NET Core, TypeScript, Angular2... but it turned out that I hated the reality of it (5 minute quickstart was about 2 days from behind the company proxy). Don't knock boring old enterprise, it generally gets stuff done.
Remy's obviously not that experienced with XML Schema; the type definition of the hyphen (probably) isn't external. Also, using an enumeration with a single element is how you do an element whose content is fixed to a particular string; it's clunky because you virtually never do anything like that. Having an element for a hyphen that actually conveys no real semantic information, that's definitely the WTF and indicates that someone has no clue at all how to write good XML or XML Schema. And the whole thing is covered in 'orrible annotations too.