• Addison (unregistered)

    ERROR: Invalid data near '<Comment '"

  • (cs)

    <W></W> <T></T> <F></F>

  • Dood (unregistered)
    Michael responds to let them no that their software hasn't changed in a month

    no?

  • Valerion (unregistered)

    <comment>My first comment got rejected because it wasn't well formed</comment>

  • Ledward (unregistered)

    In Soviet Russia, tags close you!

  • skin256 (unregistered)

    Hah! My old boss must have designed that web service, I was told the same thing before. Should have seen the glazed look in his eye when I mentioned XSLT.

  • (cs)

    That probably means they wrote their own homebrew XML parser. That's a smart idea because no languages have any built-in XML support.

  • (cs)

    Well, if ClearPath's XML was just like the competition's XML there'd be nothing to distinguish them, right? Duh. Programmers just don't understand business.

  • Addison (unregistered) in reply to akatherder
    akatherder:
    That probably means they wrote their own homebrew XML parser. That's a smart idea because no languages have any built-in XML support.

    lol you said "homebrew". I love that word.

  • RiF (unregistered)

    I optimistically post:

    <funnycomments>
  • noone (unregistered)
    </funnycomments>
  • Fred Flintstone (unregistered) in reply to Dood
    Dood:
    Michael responds to let them no that their software hasn't changed in a month
    no?
    No, our software hasn't changed! It must be your fault!
  • (cs)

    We've had the same problem, from a large UK satellite TV company.

  • (cs) in reply to akatherder
    akatherder:
    That probably means they wrote their own homebrew XML parser. That's a smart idea because no languages have any built-in XML support.
    Well sure, they have XML support, but it's clearly buggy. Just look at all the malformed tags they accept.
  • (cs)

    And obviously the author has his own version of orthography... :þ

  • (cs)

    While empty tags are part of the spec, they could insist on <tag></tag> rather than <tag /> for a variety of esoteric reasons...

    I've seen official parsers barf, or behave in ways you wouldn't expect, on empty tags. Especially empty tags with attributes.

    Having a version that previously accepted empty tags, and now doesn't, probably suggests that in improving their error alert & detection they've created more problems. Since the application on the client end hadn't changed for a month and the new release on the other end is therefore NOT backwards compatible. Which might have been in the release notes, but I doubt it.

  • Ralph Wight (unregistered)

    Why shouldn't everyone make up their own version of XML? It worked fine for HTML.

  • Anonymous (unregistered)

    That would be the point where I passive-aggresivey just send back a reply with only a link to the appropriate point in the XML specifications. This is when the person on the other end stops replying for a while

    Been there, done that...

  • Me (unregistered)

    Actually, <tag /> is not the same as <tag></tag>. Have a look at the script tag in XHTML for example. You have to write <script src="..."></script>. Just writing <script src="..." /> is invalid.

  • (cs)
    Article:
    <Carrier />

    A space before the slash? And tag names that contain upper case characters? I'd reject that too if I were a parser :)

  • Matt (unregistered)

    I've worked with plenty of web services in the travel industry (which seems to have an abnormally high level of bad software) where I have encountered this problem. In fact every web service I have ever had to write a client for has had some horrific fail hidden away somewhere that takes longer to code around than developing the rest of the client.

  • (cs) in reply to Me
    Me:
    Actually, <tag /> is not the same as <tag></tag>. Have a look at the script tag in XHTML for example. You have to write <script src="..."></script>. Just writing <script src="..." /> is invalid.

    Funny, because [image] is valid. As is
    . <script> is the <a rel="nofollow" href="http://aspnetresources.com/blog/empty_vs_nonempty_html_tags.aspx" target="_blank" title="http://aspnetresources.com/blog/empty_vs_nonempty_html_tags.aspx">exception</a>, rather than the rule.</p> </script>

  • jc (unregistered)

    I've worked on a number of implementations of standards where I got explicit orders from above to not implement some specific part of the standard, because it "isn't needed". Inevitably, after the first deliveries, the customers make it clear that they paid for the standard and they won't accept delivery until the standard is implemented. So I'd be asked "How fast can you implement those parts we ordered you not to implement?" I learned early to keep a copy of my original do-not-implement orders, so when they tried to pin the omission on me, I could send them a copy of the original orders, to make it clear that I understood what they were trying to do. In one case, when they started the "version 2.0" phase, I again got an order to not implement the same things I'd been ordered to not implement in phase 1. I updated my resume and had a new job two weeks later.

  • Steve (unregistered) in reply to Ledward
    Ledward:
    In Soviet Russia, tags close you!
    Win.

    Thread over.

  • NM (unregistered) in reply to fruey

    [quote]I've seen official parsers barf, or behave in ways you wouldn't expect, on empty tags.[quote]

    I call <bs/>

    Empty tags have been part of XML from the beginning. There is no reason but ignorance / stupidity to barf on them.

    It's even more stupid than that braindead developer in the other room who doesn't understand that you should use 'void *' and not 'char *' when a pointer goes to various types. At least, there was a time (1979?) when that wasn't completely retarded, because 'void' wasn't a part of the C language yet.

  • Hasteur (unregistered)

    There's a time and place for homebrewed software to process data (exceedingly esoteric company trade secret formats that resemble XML) and a time and place for using standards compliant system software to process the data (Properly Validating XML transactions). I would like to give the benefit of the doubt that while the transaction content may look like XML it's actually a very carefully crafted proprietary format that is documented only on toilet paper that was used about 20 minutes before the format processing was changed.

    Here's to having well documented standards when exchanging data with any piece of software that is not 100% under your control.

  • (cs)

    I had something similar recently.

    I'm working on an interface between our software and another vendor. I'm using PHP and we're communicating with XML. Obviously I'm using the DOMDocument class in PHP to generate my XML. Most of the elements have short bits of text in them, but a couple elements are longer messages with line breaks and such where the whitespace is important. So, I made sure to put the "xml:space" attribute on those elements so that my serializer didn't chomp out the whitespace (and most likely, the other guy's parser). When we were testing, the other asked that I remove that pesky "xml:space" thing because he wasn't expecting it when he was parsing the XML.

    Of course he was parsing the XML line by line as plain text, probably using regular expressions. I kinda suspected this from the beginning - almost every vendor's XML API I've ever seen has some tell-tale clue in it that proves to me that they're not using a real XML parser and they're going to freak out if I include, say short tags for empty elements. It's always hard to ask that question of another developer without sounding like you're asking "Are you a dumbass?"

    You really shouldn't be allowed to use XML unless you at least know the DOM Level 1 API (that's implemented in every language I've seen) and maybe even some XPath.

  • (cs)

    I know a certain major bank whose "web service", AKA an email address that you send XML to, doesn't like "malformed" XML either. It also doesn't like when you switch the element order. That is

    <wtf>foo</wtf> <hi>there</hi>

    was not treated the same as <hi>there</hi> <wtf>foo</wtf>

    It's a sad thing.

  • (cs) in reply to nikki9696
    nikki9696:
    I know a certain major bank whose "web service", AKA an email address that you send XML to, doesn't like "malformed" XML either. It also doesn't like when you switch the element order. That is

    <wtf>foo</wtf> <hi>there</hi>

    was not treated the same as <hi>there</hi> <wtf>foo</wtf>

    It's a sad thing.

    It is indeed. In fact, you might as well not use tags at all, but some easier structured exchange format.

  • Michael Thompson (unregistered)

    Arguably there is a difference between "<sometag />" and "<sometag></sometag>" -- the latter has an empty text node as a descendant and the former it fully empty.

    In either case, however, I have no idea how you could write your own XML parser and not handle self-closing tags.

  • (cs) in reply to NM
    NM:
    fruey:
    I've seen official parsers barf, or behave in ways you wouldn't expect, on empty tags.

    I call <bs/>

    Empty tags have been part of XML from the beginning. There is no reason but ignorance / stupidity to barf on them.

    It's even more stupid than that braindead developer in the other room who doesn't understand that you should use 'void *' and not 'char *' when a pointer goes to various types. At least, there was a time (1979?) when that wasn't completely retarded, because 'void' wasn't a part of the C language yet.

    Empty tags may have been part of the spec from the beginning, but then so what? Doesn't mean parsers don't sometimes have rather poorly documented ways of reacting to unexpected XML. Especially when you're already hacking input files that are malformed in the first place.

    Ever been to this hell?

  • (cs) in reply to fruey

    It's not an except if you're using actual XML parsed as XML and not pseudo-XML parsed as HTML.

    http://hixie.ch/advocacy/xhtml

    Appendix C of XHTML 1.0 is the worst thing to ever happen to web standards because it's caused people to think things like the above-quoted.

  • JD (unregistered)

    You see, this is exactly why we have standards - so idiot vendors can break them and make our lives ten times harder.

  • (cs) in reply to Dood
    Dood:
    Michael responds to let them no that their software hasn't changed in a month

    no?

    You know what is sad? I've gotten so used to people writing "no" for "know" that I don't even notice anymore...

  • (cs) in reply to Michael Thompson

    No there's not. A parser wouldn't create an empty text node in the DOM.

  • (cs)

    To clients of the former ClearPath Logistics:

    inspired by a rash of connection issues involving our insistence on using our in-house subset of XML, we have opted to rename our company to more accurately reflect your experience in dealing with us. Henceforth, please refer to the company as "MurkyPath Illogistics".

    Regards

  • kirkjerk (unregistered) in reply to fruey

    I'm surprised that specified tag order seems to be a default in XML, and it's surprisingly difficult to be liberal about it and a lot of DTD type things.

  • (cs) in reply to Kermos
    Kermos:
    You no what is sad? I've gotten so used to people writing "no" for "know" that I don't even knowtice anymore...
    Fixed that for you.
  • John (unregistered) in reply to levi_h
    levi_h:
    Article:
    <Carrier />

    A space before the slash? And tag names that contain upper case characters? I'd reject that too if I were a parser :)

    Umm, what's the problem with whitespace before the slash?

  • Tephlon (unregistered) in reply to Steve
    Steve:
    Ledward:
    In Soviet Russia, tags close you!
    Win.

    Thread over.

    Come on, at least use </thread> ...

  • (cs)

    Look. The way I understand XML, the way I was taught, it is up to the receiving party to define the standard they are willing to accept, so this means things like which conventions from the spec will apply with any XML conversation you have with them.

    One BIG reason I can think for them making this design decision is for performance. I mean if you have to look for closed tags two different ways, then that is twice as much processing time. Another reason might be cost for development, I mean why would you want to write extra unnecessary code.

    So you might be saying, .NET (or Java) already has an XML library included standard. But again this has distinct disadvantages. First, you have to ask can you trust this implementation. I personally have found more bugs in the .NET framework than I can remember. I wish I had kept a list of them so I could tell you. Second, .NET gives you only a general-purpose XML implementation, so the developer still has to write a lot of processing code... or use XPath, but don't get me started on XPath, it has burned us on multiple occasions, so we have banned it.

    But the bottom like is any decent developer should be able to write a specialized XML library that is easier to use and out-performs the generic XML library included in .NET.

  • Horamash (unregistered) in reply to Dood

    At least it wasn't spelled as "now".. If I'd get a dollar for everytime I saw that, I'd still be poor, no matter how many times people'd do that, so I'll only accept euro's now, it'll make me rich!

  • Keith (unregistered)

    I now no why their is know way to no that there are know intelligent programmers working four you're vendor until its to late.

    Does you're head hurt?

  • Me (unregistered) in reply to Tephlon
    Tephlon:
    Steve:
    Ledward:
    In Soviet Russia, tags close you!
    Win.

    Thread over.

    Come on, at least use </thread> ...

    Tephlon or "Telefon"?

    http://en.wikipedia.org/wiki/Telefon

  • Martin (unregistered) in reply to nikki9696

    <wtf>foo</wtf> <hi>there</hi>

    was not treated the same as <hi>there</hi> <wtf>foo</wtf>

    It's a sad thing.

    So, you are saying this banks XSD or DTD defines an XML sequence, and the parser correctly throws an error when it encounters an incorrectly ordered sequence of elements?

    How is their compliance with the standards sad?

  • Machtyn (unregistered)

    Simple notepad++ regexp find and replace for those pesky empty tags... Find what: <([a-zA-Z0-9]*) /> Replace with: <\1><\1>

  • Nerf Herder (unregistered) in reply to Ledward
    Ledward:
    In Soviet Russia, tags close you!

    I dont know who votes on featured comments, but if this isn't blue by the end of the day there is a conspiracy.

  • Nerf Herder (unregistered) in reply to Kermos
    Kermos:
    Dood:
    Michael responds to let them no that their software hasn't changed in a month

    no?

    You know what is sad? I've gotten so used to people writing "no" for "know" that I don't even notice anymore...

    Its the same with people writing "you" instead of "your". I realize its a different case because they are not homophones, but so many people for whatever reason cannot type "your" correctly.

    I cannot count how many times a week I read something like: "Don't forget to submit you timesheets by Friday"

    Drives me nuts

  • ethan (unregistered) in reply to Me
    Me:
    Actually, <tag /> is not the same as <tag></tag>. Have a look at the script tag in XHTML for example. You have to write <script src="..."></script>. Just writing <script src="..." /> is invalid.

    Apparently you don't understand the difference between "XML" and "XHTML". Empty tags are always legal in XML and should always be treated exactly the same as open tag followed immediately by a close tag.

    XHTML is an attempt to produce valid XML which can nonetheless make it through existing web browser's HTML parsers, which were not designed to parse XML. So yes, when you're producing XML which has to make it through a parser which wasn't designed to parse it, it turns out that you can't just use any old XML you like.

    However, if you are sending data to an actual XML parser which doesn't accept empty tags, the implementors need to be shot. Since this XML wasn't being sent to a web browser, we are clearly in "shoot the bastards" territory.

  • Joey (unregistered)

    What's wrong with a space before a terminating slash?

    Simple.

    <tag /> <---- Hack to work with SGML as well, particularly HTML when writing XHTML.

    <tag/> <--- How it should be.

    The /> are as much one thing as </

    You wouldn't have </ tag>, < tag> or <tag attribute="" >

Leave a comment on “The Substandard Standard”

Log In or post as a guest

Replying to comment #220287:

« Return to Article