• HDS (unregistered)

    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.

  • Ron Fox (google)

    Fristly speaking I got confused by the term 'Schema' and then I realized he just meant a DTD.

  • DocMonster (nodebb)

    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.

  • Quite (unregistered) in reply to DocMonster

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

  • Lothar (unregistered)

    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.

  • J. (unregistered) in reply to Ron Fox

    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)

  • J. (unregistered) in reply to Lothar

    They use <xsl:sequence>, so yes, order of tags are strict and all of them are mandatory.

  • Stephan L. (unregistered) in reply to DocMonster

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

  • Pedant (unregistered)

    But what's an extrenal schema?

  • CoyneTheDup (nodebb)

    I've never seen a hyphen so well-defined.

  • Confused (unregistered)

    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?

  • Confused (unregistered)

    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?

  • Erik (unregistered) in reply to Confused

    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.

  • JustHere (unregistered) in reply to Quite

    "...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.

  • Jerepp (unregistered)

    Can't wait for version 2.0 of the HyphenType!

  • bvs23bkv33 (unregistered)

    only byte buffers with platform- compiler- and architecture-dependent alignments! sorry only byte buffers with platform<hyphen> compiler<hyphen> and architecture<hyphen>dependent alignments!<p> </hyphen></hyphen></hyphen>

  • CouldBeWorse (unregistered)

    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.

  • time0ut (unregistered) in reply to Quite

    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.

  • Kashim (unregistered)

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

  • Ulysses (unregistered)

    But there is an Easy Reader Version of an XML schema, thanks to nodebb. <?xml version="1.0" encoding="UTF-8"?

  • slavdude (nodebb)

    XML schemas--the 2000s equivalent of JavaScript libraries.

  • Simon (unregistered)

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

  • MaxArt (unregistered) in reply to Kashim

    That's brillant.

  • dgatwood (unregistered) in reply to JustHere

    I would imagine that the processing code is something along the lines of

    1. Strip out the whole-degrees tag.
    2. Strip out everything else that isn't inside a tag.
  • PaulMurrayCbr (unregistered)

    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.

  • Brian the Superninja (unregistered)

    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.

  • Hans de Great (unregistered) in reply to J.

    A DTD is used to define (describe or whatever) a schema. The schema is used to define other xml's All SGML!

  • löchlein deluxe (unregistered)

    So if you mind, just write a XSLT to remove the hyphen ::troll::

  • Hans de Great (unregistered) in reply to Brian the Superninja

    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.

  • tjdracz (unregistered)

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

  • Brian the Superninja (unregistered) in reply to Hans de Great

    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.

  • dkf (nodebb)

    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.

  • Mitch (unregistered)

    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.

  • sasa (unregistered)

    Intinya GEJALA SINUSITIS Ini Dapat Terjadi Pada Pria Maupun Wanita Diberbagai Usia. Untuk Itu Jangan Remehkan GEJALA SINUSITIS. Metode Pengobatan Herbal Biasanya Menjadi Alternatif Dalam Penyembuhan GEJALA SINUSITIS, Karena dengan pengobatan herbal GEJALA SINUSITIS Ini Akan Terobati Tanpa Dengan Disertai Efek Samping Yang Berbahaya. Dengan Keunggulan Inilah Yang Membuat Pengobatan Herbal Menjadi Alternatif Dalam Mengobati GEJALA SINUSITIS Secara Alami. Untuk Itu Atasi GEJALA SINUSITIS Sekarang Juga Sebelum GEJALA SINUSITIS Ini Menjadi Berbahaya

  • sasa (unregistered)

    GEJALA SINUSITIS Biasanya sering muncul pada seseorang dengan penyakit sinusitis . GEJALA SINUSITIS Ini Biasanya Ditandai Dengan Munculnya Gangguan Pada Daerah Sinus. Tak Sedikit Penderita Yang Terganggu Dengan Munculnya GEJALA SINUSITIS Ini. Maka dari itu jika anda ingin terbebas dari GEJALA SINUSITIS, Anda Dapat Melakukan Pengobatan Yang Benar Benar Optimal. Pengobatan Yang Dilakukan Harus Benar Benar Ampuh Agar GEJALA SINUSITIS Ini Benar Benar Terobati. Biasanya GEJALA SINUSITIS Dapat hinggap pada siapapun diberbagai usia. Tak sedikit GEJALA SINUSITIS Yang Muncul Pada Pria Dan Wanita.

  • sasa (unregistered)
  • sasa (unregistered)

Leave a comment on “Sche-ma”

Log In or post as a guest

Replying to comment #:

« Return to Article