• Azeroth (unregistered) in reply to Willie
    Willie:
    There's a maximum tag name specification? Where?

    uh, oh, ALex, what have you done...

  • (cs) in reply to real_aardvark
    real_aardvark:
    You can, however, change the subject.

    Well, an enormous number of posts on this site do just that; but you get my drift. Speaking of which, Jarse is misquoting Milligan egregiously. I mean, the whole point of the joke was that the first name was "Hugh."

    And did you know that "Biggar" is a semi-popular name in Scotland, and that there is, or was, a Reverend Biggar Balls?

    I confess to having no idea what you're talking about. I assume it has something to do with yesterday's discussion of the use of "comprise", mentioned in an earlier post. Yesterday's WTF offerings did not capture my interest. Nor did the first several responses; so I stopped reading them early on, and therefore missed what must have been an entertaining side discussion.

    Which just goes to show that side discussion, i.e. changing the subject, is not only to be expected; it is to be welcomed. However, I'm not motivated to go tracking down the "comprise" controversy on my own. If some philanthropic soul wants to post a link to the starting post of the discussion, I'll follow that up for the sake of knowing the inside joke.

  • me (unregistered) in reply to IMSoP
    IMSoP:
    Paul:
    Now, if they returned /p604332/front.jpg,12612,75,43,A Big Shoe /p604332/back.jpg,25462,120,60,The Back of A Big Shoe

    tha would be far more efficient, easier to code, and far quicker to generate and parse.

    Until someone enters a caption with a comma in it of course. So, maybe you could put the fields in quote-marks; and have a format for escaping quote-marks.

    Or maybe you could separate with some wacky character like '¦', in the hope that no-one will type that one.

    Or maybe you could put them in key-value pairs with well-defined quoting and escaping - i.e. XML attributes. I really don't see what people find so offensive about that.

    Normally in a | delimited list, you can escape any character using a backslash, just like in c (or most other language) strings, you just have to remember that | is also escaped.

    The other format which could be better would be an INI format, using the filename as the heading and then having only three restrictions: no = or whitespace in the key, and no unescaped newlines in the value

  • Joon (unregistered)

    Steve should have given them an XML Schema in XSD, XDR or eved DTD format, then they would have known what exactly he wanted, or maybe even just a spec

    By just asking for it as "XML" without defining how exactly he wanted the data, he is as culpable as they are for this one...

  • (cs) in reply to Joon
    Joon:
    By just asking for it as "XML" without defining how exactly he wanted the data, he is as culpable as they are for this one...

    He should have asked to get the data as binary, in which case the data would obviously have contained all relevant information.

  • Alak (unregistered) in reply to Joon
    Joon:
    Steve should have given them an XML Schema in XSD, XDR or eved DTD format, then they would have known what exactly he wanted, or maybe even just a spec

    By just asking for it as "XML" without defining how exactly he wanted the data, he is as culpable as they are for this one...

    Exactly my thoughts. Crap in, crap out.

    Without specifications you never know what to design. They probably spent an week creating a xml wrapper on their system, now if they only had provided a schema.

    Just asking for stuff and expecting you to be able to read their minds is just silly and the real WTF here..

  • Shinobu (unregistered) in reply to confused

    Yes, using XML for what is essentially tabular data...

  • josephdietrich (unregistered) 
    <comment captcha="pinball">
  <reaction type="verbal">
    Aaaauuuggh! Nooo!
  </reaction>
  <reaction type="physical" action="crying" />
  <reaction type="emotional" state="depressed" />
</comment>
  • IMSoP (unregistered) in reply to Joon
    Joon:
    Steve should have given them an XML Schema in XSD, XDR or eved DTD format

    I suspect this is exactly what everyone here, probably rightly, dislikes about using XML in situations like this - there is absolutely no need for such formal specifications in this case, XML is just one among many convenient formats for transmitting structured data.

    As I've said before, if they really suffered from acute XML-phobia, they should have offered him the information he needed in an alternative format.

    By just asking for it as "XML" without defining how exactly he wanted the data, he is as culpable as they are for this one...

    Well, we don't know the details, but the article strongly implies that he gave them at least a partial list of additional fields required, none of which were provided.

    Nor is there any suggestion that the providers of the data got back to him and asked for clarification - implementing something so monumentally pointless as this without clear confirmation that it is actually required is, quite frankly, inexcusable.

  • IMSoP (unregistered) in reply to me
    me:
    Normally in a | delimited list, you can escape any character using a backslash, just like in c (or most other language) strings, you just have to remember that | is also escaped.

    The other format which could be better would be an INI format, using the filename as the heading and then having only three restrictions: no = or whitespace in the key, and no unescaped newlines in the value

    OK, fair enough, there is more than one way of formatting such data, XML is neither a panacea, nor should it have a monopoly on use as a data format. Maybe in this case it wouldn't have been the best choice - the INI-style sounds fairly appropriate from what we know of the requirements.

    But I was responding to this:

    Paul:
    tha would be far more efficient, easier to code, and far quicker to generate and parse.

    By "efficient", I presume the meaning is that you save a lot of bytes with each response; but unless your service is sending large volumes of data, or to large numbers of users, this is really unlikely to be a problem with modern connectivity.

    Easier to code? Maybe; depends how you do it, and in what environment; maybe you have some handy XML-parsing functions to hand that will give you back just what you need. Or maybe you have some INI-parsing functions, or a good enough understanding of regular expressions to handle some agreed delimiting and escaping, etc.

    As for quicker to parse, the point about volume applies again - processing power is pretty cheap these days - but granted, using a full-fledged XML parser might produce unnecessary overhead. Although there's no reason you can't make a couple of efficient regexes to parse the XML, just like you would any other form of delimiting and escaping...

    Quicker to produce, I just don't buy - for simple data like this, you're just going to be doing simple string manipulation whatever format you produce.

    Like I say, maybe XML isn't perfect for this application, but it's certainly not an insane suggestion to get the job done if those are the tools you happen to have lying around.

  • (cs) in reply to FredSaw
    FredSaw:
    real_aardvark:
    You can, however, change the subject.

    Well, an enormous number of posts on this site do just that; but you get my drift. Speaking of which, Jarse is misquoting Milligan egregiously. I mean, the whole point of the joke was that the first name was "Hugh."

    And did you know that "Biggar" is a semi-popular name in Scotland, and that there is, or was, a Reverend Biggar Balls?

    I confess to having no idea what you're talking about. I assume it has something to do with yesterday's discussion of the use of "comprise", mentioned in an earlier post. Yesterday's WTF offerings did not capture my interest. Nor did the first several responses; so I stopped reading them early on, and therefore missed what must have been an entertaining side discussion.

    Which just goes to show that side discussion, i.e. changing the subject, is not only to be expected; it is to be welcomed. However, I'm not motivated to go tracking down the "comprise" controversy on my own. If some philanthropic soul wants to post a link to the starting post of the discussion, I'll follow that up for the sake of knowing the inside joke.

    I can obviously bugger on and on and on(and obviously have done) about "comprise" until the cows come home.

    On the other hand, you're quoting me whilst I'm changing the subject, ie not buggering on and on and on ... well, not about the proper use of the "C" word.

    I assume your problem lies with identifying (Spike) Milligan, the man wot wrote the Goon Show, which in turn propelled Peter Sellers to stardom and foreshadowed things like the Pythons.

    Spike and Peter were in the habit of phoning up unsuspecting receptionists at the BBC, where they worked, and asking to get in contact with fictitious individuals with unfortunate names. No mobile phones or pagers in the 1950s, so the hapless and innocent receptionist would resort to yelling over the tannoy:

    "Is there a Hugh Jarse in the building?"

    I imagine you see the point.

    Calling oneself "Huge Jarse" is a crime against a comic genius, in my opinion.

  • (cs) in reply to IMSoP
    IMSoP:
    Like I say, maybe XML isn't perfect for this application, but it's certainly not an insane suggestion to get the job done if those are the tools you happen to have lying around.
    Look, translating it into bleeding Pushtun and back isn't an insane suggestion to get the job done if those are the tools you happen to have lying around.

    Looking top-down (and not down-up, which most XML enthusiasts seem to do) at this, there are a series of choices to be made:

    (1) Same flavour of system at each end (eg C or Java)? Send it as a struct or as serialised data. (2) Different flavours, same platform (eg Windows)? Send it as a zip file, presumably including the JPEG and an ini-style key=value text file. (3) Incomprehensibly different platforms, at least one of which can't, for some reason, generate or accept either the zip format or the ini format ... no, wait, my head just exploded.

    (CSV works perfectly well as an alternative to step 2, btw.)

    There is no deep structure evident in the requirements here. There is no business-critical need to validate the "document" (how I love it when XMLers misuse this term. In fact, it's difficult to see how you might usefully validate it. XML certainly wouldn't help at the semantic level.) There is no predefined (XML) format with which the supplier must comply. There is no need for future generations to interoperate, globally, with the protocol.

    In short, there is no need for XML at all. Period.

    Parsing? Parsing? Don't get me started on XML parsing.

    The implicit business needs here are X globs of data, where X is between 3 or 4 and infinity. No structure. No tree. No parsing.

    The only tool involved is the tool who wrapped the original format in "XML." That tool might well be lying around. Like a number of XML tools I could name, however, he should be shot in the head and not encouraged to produce abortions like the OP.

  • IMSoP (unregistered) in reply to real_aardvark
    real_aardvark:
    (1) Same flavour of system at each end (eg C or Java)? Send it as a struct or as serialised data.

    Arguably, all data formats are "serialised data"; that's kind of the point. But yeah, if you're using the same system both ends, use something nicely integrated with that system.

    (2) Different flavours, same platform (eg Windows)? Send it as a zip file, presumably including the JPEG and an ini-style key=value text file.

    Woah, there! What? Who mentionned anything about ZIP files with images in them?

    (CSV works perfectly well as an alternative to step 2, btw.)

    But XML, for some reason, doesn't; I don't get it.

    The implicit business needs here are X globs of data, where X is between 3 or 4 and infinity. No structure. No tree. No parsing.

    Oh yeah, I forgot, you can dump an INI-file into memory and instantly access it as a data-structure in your program. No, no need to parse it at all!

    We're talking a small stream of data, which needs some agreed, very simple, formatting. A simple XML format - no validation, no fancy definitions, just using key="value", wrapping items in '<type' and '/>', and escaping the handful of characters you've then "reserved" - is pretty much as good as anything else, and you might just happen to have pre-written functions to read and write it. Why does it have to be a big deal?

  • Shill (unregistered) in reply to real_aardvark
    real_aardvark:
    Shill:
    real_aardvark:
    Incidentally, is it just me, or is calling someone you don't know a "nazi" just a tad offensive?

    No more or less offensive than wearing a hat in a restaurant.

    But what if the hat is a yarmulke?

    (Just in case you didn't get the "someone you don't know" bit.)

    All religious headgear is exempt from the "no wearing hats inside" rule of etiquette.

    I have no idea how thinking about the case when the "hat" is a yarmulke is supposed to call attention to the "someone you don't know" bit.

  • (cs) in reply to Shill
    Shill:
    real_aardvark:
    Shill:
    real_aardvark:
    Incidentally, is it just me, or is calling someone you don't know a "nazi" just a tad offensive?

    No more or less offensive than wearing a hat in a restaurant.

    But what if the hat is a yarmulke?

    (Just in case you didn't get the "someone you don't know" bit.)

    All religious headgear is exempt from the "no wearing hats inside" rule of etiquette.

    I have no idea how thinking about the case when the "hat" is a yarmulke is supposed to call attention to the "someone you don't know" bit.

    I suppose real_aardvark somehow thinks that it would be offensive to call somebody a nazi, only if he or she is Jewish. In much the same way that only Americans find it offensive to be called communist.

  • (cs) in reply to IMSoP
    IMSoP:
    (CSV works perfectly well as an alternative to step 2, btw.)
    But XML, for some reason, doesn't; I don't get it.
    Easy: too much effort, too little reward.

    "Parsing" CSV requires little more than the standard C runtime library. (Wrappers would be nice, but not necessary on a tiny little problem like this.)

    Parsing an XML document requires something more heavyweight, and depends upon a third-party library. (Like the C runtime library ain't third-party; I know, I know ...)

    I don't disagree that XML would work in this case. I don't see the point of it, but then I don't see the point of translating the text into Pushtun and back. Heck, do whatever plugs the void for you.

    I think we'd both agree that the choice of format is a bit of a side-show. Hell, I hate XML, but I've put in bids on a couple of projects to use it. (Maybe if I'd won one of them, I'd love the gnarly little bugger.)

    But, three weeks to produce something that could quite literally be done by prepending 18 characters and appending another 3? This is not a requirements issue. This is not a design issue. This is not a parsing issue. This is purely ... <ta-daaah!> a Worse Than Failure issue.

    IMSoP:
    Oh yeah, I forgot, you can dump an INI-file into memory and instantly access it as a data-structure in your program. No, no need to parse it at all!
    Sorry, I forgot that modern processors are optimised to dump an XML document into memory and instantly access it as a data-structure in your program. My bad.
  • (cs) in reply to java.lang.NullReferenceException
    java.lang.NullReferenceException:
    real_aardvark:
    But what if the hat is a yarmulke?

    (Just in case you didn't get the "someone you don't know" bit.)

    I suppose real_aardvark somehow thinks that it would be offensive to call somebody a nazi, only if he or she is Jewish. In much the same way that only Americans find it offensive to be called communist.
    Bad supposition. Try again.

    Calling anybody a nazi, irrespective of race or creed, is exceptionally offensive and in my opinion suggests brain damage of the variety that requires a lobotomy. My mention of specific Jewish headgear was intended as a gentle prod to indicate that, since you don't know who you are gratuitously associating with the Third Reich, you might accidentally be causing somebody real pain and anguish.

    The comment to which I replied mentioned hats. Had it mentioned pants/trousers, I could equally well have used lederhosen as an exemplar. Not too many Germans like being called nazis, either.

    I assume that you ain't American, because I've never met one who would find it "offensive" to be called a communist. Either (unlikely) they are one, or they'd just find it funny and then break your nose, just to carry on the joke.

    Anyway ... what were we talking about?

  • IMSoP (unregistered) in reply to real_aardvark
    real_aardvark:
    Easy: too much effort, too little reward.

    "Parsing" CSV requires little more than the standard C runtime library. (Wrappers would be nice, but not necessary on a tiny little problem like this.)

    Sure, like I say, as long as you don't need any escaping, you're just splitting on ',', or '|', or whatever. As soon as you've got escaping, or quoting and escaping, you're into a few lines of string manipulation, or regexes, or some such.

    real_aardvark:
    Parsing an XML document requires something more heavyweight, and depends upon a third-party library.

    Why? It's still just string manipulation. You're still just splitting on delimiters and replacing escapes.

    Again, wrappers and external libraries might be handy, but you don't need them for "a tiny little problem like this". You've just got to get the data out.

    Just because you're sending something in XML format doesn't mean you have to use 5 namespaces, 6 DTDs, and 7 XSLT templates. It's just a format FFS!

    real_aardvark:
    I think we'd both agree that the choice of format is a bit of a side-show.

    Oh, absolutely, I'm not defending the WTF in any way, only XML. And I'm not defending those who claim it as some kind of magic bullet, which somehow solves all problems and supercedes all data formats ever, either, by the way. People make some really stupid claims about XML, and do some really stupid things with it; but at the end of the day, it's a convenient way of presenting a bit of data as a string of characters.

    real_aardvark:
    IMSoP:
    Oh yeah, I forgot, you can dump an INI-file into memory and instantly access it as a data-structure in your program. No, no need to parse it at all!
    Sorry, I forgot that modern processors are optimised to dump an XML document into memory and instantly access it as a data-structure in your program. My bad.
    That was a response to your comment about "No structure. No tree. No parsing." I probably misunderstood, but you made it sound like XML needed parsing, but your suggestion (an INI-file) would somehow parse itself.
  • Nelle (unregistered) in reply to Paul
    Paul:
    obediah:
    I hope so. Out of my semi-rational XML hatred, I would have made about the same change.

    I have the same loathing. I can think of about 3 billion easier, quicker & more efficient ways to return the desired data than to use XML..

    It looks to me like more a bad feature request. They probably DID do their best. It probably took a few weeks just because it was a low priority task, and there's probably no one there who knows XML - why should they, it's an awful system so why should anyone have to suffer learning about it?

    Now, if they returned /p604332/front.jpg,12612,75,43,A Big Shoe /p604332/back.jpg,25462,120,60,The Back of A Big Shoe

    tha would be far more efficient, easier to code, and far quicker to generate and parse. If Steve had been sensible and asked for something like that, he'd probably have got it, as the developer would have spent his time doing the job rather than having to try to learn about something that should never have been invented.

    /p604332/happy.jpg,25462,120,60,I am happy, at least sometimes

  • Ada Lovelace (unregistered) in reply to NeoMojo

    Is the WTF that they're using JPG instead of PNG? ;)

    How complete is PNG support in browsers? I know all the current versions can handle it, but at some point IE did not. The last time I worked on a site I was specifically told not to use PNGs. Were they being too cautious?

  • (cs)

    While I do love the INI format for trivial tasks, it feels a little bit limited. It has no inherent support for nested or repeating structure. I don't think there's any support for line breaks in the text values either.

    XML makes structure a lot more natural, but my complaint about XML is mostly that there are too many ways to structure the tags. Would you write this:

     <item>
  <propertyA>value 1</propertyA>
  <propertyB>value 2</propertyB>
 </item>

    or

     <item>
  <propertyA value="value 1" />
  <propertyB value="value 2" />
 </item>

    or even this?

     <item propertyA="value 1" propertyB="value 2" />

    And why? INI files are even more of a make-up-your-own-format when it comes to finding ways to specify structure. For example, you'd end up with nonsense like:

    [input.section.item(1)]
propertyA=value 1
propertyB=value 2

    Without formal structure, you get horribly verbose section names according to your own made-up rules of how to represent structure.

    The advantage, to me, of XML is that it just works. It's popular, widely supported and gives you structure automatically in a way that all tools will read. No made-up formats. But if we could replace it with something a little bit more terse, and a little less haphazard in how you're to use it, that would be fine!

  • (cs)

    BTW, if we all petitioned Alex, do you think he'd fix his shitty BBCode to HTML conversion? Previewing code tags at a URL not included in my user CSS ruleset reminded me that all code on this site is double-spaced, and code tags, like quote tags, get excessive linespace. The real WTF is replacing Community Server for something that does a worse job than what it replaced :P updates CSS ruleset to include preview pages

  • Maxi (unregistered)

    In all fairness - the problem here is that he asked for an XML format.

    If he'd asked for the extra information, but not asked for the XML, he might actually have got what he wanted.

    And no that does not explain what he got back - but its true :p

  • Jürgen (unregistered)

    That German version is soo wrong. It is a WTF for itself. I am German but to me the idea of translating error boxes and source code comments is the most ridiculous idea I have come across ever. Please shut this site down for good.

    (Captcha is "ewww")

  • IMSoP (unregistered) in reply to Ada Lovelace
    Ada Lovelace:
    How complete is PNG support in browsers? I know all the current versions can handle it, but at some point IE did not. The last time I worked on a site I was specifically told not to use PNGs. Were they being too cautious?

    IE had no alpha transparency support for PNGs until version 7; there were other problems too, but if you use palette-transparency, like with a GIF, it looks basically fine on IE 4 and up. See http://www.libpng.org/pub/png/pngapbr.html for details. [There are also horrible ActiveX workarounds to let you use alpha transparency in IE 5 & 6.]

    Of course, if you're only using features also available in GIF, there's not much point - or not since the GIF patents expired, eliminating the legal advantage.

  • (cs) in reply to Cuttie McPasty
    Cuttie McPasty:
    Ditto - seems you have to start somewhere. The RealWTF(tm) is not recognizing this as progress.

    It appears you missed this in the original post:

    They assured him that they'd do their best and, a few weeks later, released their latest XML-based API.

    A few weeks later they'd come up with this? And you count that as "progress"? You must work for a real true enterprise operation.

  • Eduardo Habkost (unregistered)

    I imagine that this happened:

    Team-A developer to Team-B Boss: I would like to have more information about the pictures, such as title, size, tags, and other product information. Maybe you could return this information somehow? In a XML document, maybe?

    Team-B boss: I will see what I can do.

    Later:

    Team-B boss to Team-B developer: They want this to be returned in XML.

    Team-B developer: WTF?

    boss: this is what they asked. They want this to be returned in XML.

    developer: this makes no sense.

    boss: just do it.

    developer: (mumbles)

  • (cs) in reply to Daniel Beardsmore
    Daniel Beardsmore:
    The real WTF is replacing Community Server for something that does a worse job than what it replaced :P

    No, the real WTF is continually bitching about the software someone else decided to use for their website. Don't like it? Don't visit the site. Want to visit the site? Quit your bitching.

    Besides, Alex wrote the software in question. It seems to work rather well IMO, and is definitely better than any of your work I've seen. :-)

  • DarkSprout (unregistered)
    Post:
    However, Steve was interested in more than just the image paths and asked if they could send back more data - file size, heading, caption, etc - and wrap it in some XML format. They assured him that they'd do their best and, a few weeks later, released their latest XML-based API. And that same request now returned this...

    <IMAGE_SET value="/p604332/front.jpg,/p604332/back.jpg,/p604332/back-alt.jpg,/p604332/in-use.jpg" />

    I don't think that the XML should be considered such a bad idea, when used correctly - it provides a lot of functionality.

    Example:

    <IMAGE_SET>
    <Object
        Title = "Front"
        Path = "/p604332/front.jpg"
        Size = "635.12"/>
    <Object
        Title = "Back"
        Path = "/p604332/back.jpg"
        Size = "567.34"/>
    <Object
        Title = "Back (alt)"
        Path = "/p604332/back-alt.jpg"
        Size = "558.32"/>
    <Object
        Title = "In-use"
        Path = "/p604332/in-use.jpg"
        Size = "678.59"/>
</IMAGE_SET>
  • (cs) in reply to real_aardvark
    real_aardvark:
    clively:
    The real WTF is that Steve had access to all of the information he needed to begin with.

    1. File size is trivial to determine once you have grabbed the file.

    2. The heading would come directly from the product information he already has. Product Name anyone?

    3. Captions can be pulled directly from the file names.

    The vendor's programmers more than likely knew this and coded to the only remaining part of the new spec: deliver it in XML.

    Well, I'm certainly not going to defend the XML bit. That would be absurd.

    However, in the spirit of trying to make sense of this mess:

    1. Oh look, this JPEG is encoded at 100% of 16 bazillion colour depth. I don't think I want to download that one.
    You're selling that product and need to show the image. You have to download it or are you suggesting the Steve just show a nice red X, or worse, no photo at all. Even if the images were large, Steve would more than likely do the simply image resizing necessary on his end to get the image to fit the space and size requirements.
    real_aardvark:
    2. Eh? Are you suggesting that there is an immutable one-to-one relationship, on both sides of this transaction, between Product Name and Product Number?
    I'm suggesting that grabbing the image is the second part of the process. The first was getting the data dump of the all of the products. Did you even look at the initial request that Steve sends to the vendor? It includes the product number.
    real_aardvark:
    3.Caption: "front", "back", "back-alt", "in-use". Elegant.
    Usually that is all that they have. Have you looked at newegg.com's pictures? The captions follow the same format. Actually, just about any eCommerce site uses this style for the captions when displaying multiple photos of a product.
    real_aardvark:
    4. You forgot the "etc."
    Without having seen the full request Steve sent there's no point in assuming that "Etc" actually exists or that those data points aren't covered already.
    real_aardvark:
    5. The vendor is presumably trying to sell something through the "in-house" system...
    The story starts off with "As an e-commerce site" Maybe you didn't quite learn reading comprehension in grade school. Let me help you. Steve has a website. Steve has product information. Steve needs pretty pictures to go with those products.
    real_aardvark:
    That said, this is still a monumental WTF. Ludicrous requirements, insane choice of technology, absurd implementation of said technology. Have I missed anything?
    All of these point to problems with Steve, not the service.
    real_aardvark:
    clively:
    The vendor's programmers more than likely knew this...
    Just felt like repeating that. You sure your moniker shouldn't be "Basilly?" You are (on the face of what we see in the OP) correct in that there's no actual written set of requirements -- which there should be -- but since when is it up to some unknown set of half-witted junior programmers to re-interpret a request for "Make it XML" into "Add eighteen characters to the front and three to the back?"
    Well the xml is well-formatted. Ergo it meets the "spec" we've seen.
    real_aardvark:
    And don't tell me that this isn't the decision of an unknown set of half-witted junior programmers. It damn well reeks of that.

    All I'm saying is that Steve requested data that he 1) definately already has; or 2) can easily acquire (image size). Even asking the vendor meet this request means that Steve is probably on the same level (or worse) as those who "filled" it.

  • IMSoP (unregistered) in reply to clively
    clively:
    real_aardvark:
    3.Caption: "front", "back", "back-alt", "in-use". Elegant.
    Usually that is all that they have.

    Usually, maybe. But maybe Steve knew that in this particular case there were nice captions he could use, because he'd seen them in other uses of the same data? Or maybe he was trying to ask if there were?

    Well the xml is well-formatted. Ergo it meets the "spec" we've seen.

    No, barring the communication problem suggested by Eduardo Habkost suggested above (which actually seems quite plausible) the "spec" was a request for extra information about each image; there is no extra information being returned here. If there was no extra information to give, the correct answer is "sorry, we don't have any information other than what we already give you".

    Like I say, a communications screw-up seems pretty likely to me - Steve's request, as relayed, made no sense, and no request for clarification filtered back to him. However badly he worded his request, the biggest WTF in that case is still that they went ahead and implemented it anyway!

  • gratemyl (unregistered)

    Has anybody considered the possibility that they might be having lots of fun laughing their asses of at how well they pranked the guy who wanted the data in XML?

    Captcha: paint - haven't used that in ages.

Leave a comment on “XML Upgrade”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article