- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
Fristly speaking I got confused by the term 'Schema' and then I realized he just meant a DTD.
Admin
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.
Admin
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 ...
Admin
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.
Admin
DTD != XML Schema
XML Schema is the file format used in the article: https://en.wikipedia.org/wiki/XML_Schema_(W3C) (And yes, it's a bloody stupid choice for a name)
Admin
They use xsl:sequence, so yes, order of tags are strict and all of them are mandatory.
Admin
I'm feeling the exact opposite (I work with ASTM & HL7 formats... they are waaaayyyyyy more readable)
BTW the hyphen is there so that when stripped of all XML tags, the resulting text is human readable...
Admin
But what's an extrenal schema?
Admin
I've never seen a hyphen so well-defined.
Admin
I fail to see what is the WTF in the article. Can someone explain it to me and also mention you know for sure you don't need various hyphens throughout the system?
Admin
I fail to see what is the WTF in the article. Can someone explain it to me and also mention you know for sure you don't need various hyphens throughout the system?
Admin
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.
Admin
"...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.
Admin
Can't wait for version 2.0 of the HyphenType!
Admin
only byte buffers with platform- compiler- and architecture-dependent alignments! sorry only byte buffers with platform<hyphen> compiler<hyphen> and architecture<hyphen>dependent alignments!
Admin
Now who wants to bet that the definitions for the minutes and degrees types are defined as character strings not numbers since it looks like they plan on a left and right zero padding.
Admin
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.
Admin
<LetterM>M</LetterM><LetterA>a</LetterA><LetterY>y</LetterY><LetterB>b</LetterB><LetterE>e</LetterE><Space> </Space><LetterT>t</LetterT><LetterH>h</LetterH><LetterE>e</LetterE><LetterY>y</LetterY><Space> </Space><LetterJ>j</LetterJ><LetterU>u</LetterU><LetterS>s</LetterS><LetterT>t</LetterT><Space> </Space><LetterW>w</LetterW><LetterA>a</LetterA><LetterN>n</LetterN><LetterT>t</LetterT><Space> </Space><LetterT>t</LetterT><LetterH>h</LetterH><LetterI>i</LetterI><LetterS>s</LetterS><QuestionMark>?</QuestionMark>
Admin
But there is an Easy Reader Version of an XML schema, thanks to nodebb. <?xml version="1.0" encoding="UTF-8"?
Admin
XML schemas--the 2000s equivalent of JavaScript libraries.
Admin
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...
Admin
That's brillant.
Admin
I would imagine that the processing code is something along the lines of
Admin
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.
Admin
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.
Admin
A DTD is used to define (describe or whatever) a schema. The schema is used to define other xml's All SGML!
Admin
So if you mind, just write a XSLT to remove the hyphen ::troll::
Admin
Indeed you are right. Moslty you do not have a lot of trouble with heavily big over-enginered enterprice XML files and schemas unles one tool fails because one is more relaxed than the other.
Admin
Oh, XML... 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...
Admin
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.
Admin
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.
Admin
This is the xml version of Adatp-3 or App-11 military messaging protocol and the schema is generated from the protocol specs. It's full of peculiarities like that.