• Antti (unregistered)

    C'mon!

    How else do you de-allocate memory and empty disks except by sending negative bytes? /dev/null actually emits negative bytes, you can prove this pip reading from /dev/null via an inverting pipe.

    It's a bit bit like the Look Around You episode extolling the virtues of negative currency.

  • kingjoebob (unregistered) in reply to dkf
    dkf:
    Edward Royce:
    Are you telling me that your library is wrapping a "<bytes>" + "</bytes>" tag pair around each and every singl *byte* of image data??
    There is one way to fix this problem. Convert each of those to something like this (with namespaces omitted for brevity): 
    <bytes>
    <bit number="0" lsb="true">1</bit>
    <bit number="2">1</bit>
    <bit number="5">1</bit>
    <bit default="true">0</bit>
</bytes>

    By doing this, you eliminate the interoperability problem of just how to represent bytes and instead have something that is easy to interpret unambiguously every time!!

    ROFL

  • (cs)

    XML - eXtra Morons Lobotomized

  • (cs) in reply to NThenUDie
    NThenUDie:
    The real WTF is that someone managed to take what was probably a simple character stream protocol, wrap it in unhelpful XML, declare it enterprise compliant and then collect a bonus or promotion. Nice job!
    You missed out "and screw it up in the process." But you're right. This is one of the few cases I can think of where both XML-lovers and XML-haters would regard the use of XML as TRWTF.

    I think it was Hunter S Thompson who once said, "I hate to advocate drugs, alcohol, XML, or insanity to anyone, but they've always worked for me." But I may have just dreamed that after some particularly dodgy Ibogaine.

  • (cs) in reply to CrazyBomber
    CrazyBomber:
    Edward Royce:
    Hmmmm.

    "<bytes>37</bytes>"

    Are you telling me that your library is wrapping a "<bytes>" + "</bytes>" tag pair around each and every singl byte of image data??

    Doesn't that blow up image sizes by 16? A 10k would become 160k. Isn't that a little ridiculous?

    Oh... My... God... Really looks that way! :|

    More than 16x. Ignoring the other tags, each <byte> tag pair adds 15 bytes (assuming 1 byte/character). But the conversion to decimal string representation means up to three bytes are used to store the actual byte itself. So that's 18 bytes to store a single byte for all values greater than 100 (0x64) -- assuming they fix the sign issue -- and that's around 60% of the data being exploded by a factor of 18, another 35% by a factor of 17, and the remaining by a factor of 16. That's a weighted average of 17.5x

    BUT we still haven't taken into account that there is apparently two spaces in front of each tag pair, and a newline after each tag pair, for a grand total of 20.5x.

    This is the definition of enterprisey...

  • (cs) in reply to Matt
    Matt:
    Bob N Freely:
    I think this is actually even more sinister than anyone here has guessed. I don't think this is meant to be a bitmap format translated to XML. As others have pointed out, it doesn't contain the information necessary to render an image (dimensions, color channels). I think each <bytes> element is actually a byte from the image file. The serialization code simply opens the file as a character stream and reads from beginning to end, writing each byte out to XML.

    Pure, unmitigated evil.

    Yep. It was a PNG, but it was a whole PNG, not image data. Yep. The actual file.

    All right.

    That really makes my head hurt.

    Please stop doing it.

  • dxbmatt (unregistered) in reply to tag

    And try being on the receiving end of an uncompressed BMP embedded in an e-mail sent out weekly by a local hotel chain advertising the same deals with no unsubscribe/opt-out (even after calling the F&B director). OK, so 2MB isn't too much to download nowawdays, but I've even sent back a compressed JPEG of the same image at decent quality for 25KB to try and help them and nothing has come of it.

  • (cs) in reply to Steve
    Steve:
    But since I have to deal with raw image data (and I mean RAW, as it comes off imaging devices in some strange format only an engineer could love), the designer's choice to not include unsigned data types, particularly unsigned byte, makes me want to scream sometimes. I've never understood why that was necessary.
    I've run into the same issue a couple of times. It doesn't actually matter if all you're doing is reading in and moving bytes about, or doing bitwise operations, since the signed/unsigned thing only matters when interpreting the byte as a value. If you need to do arithmetic on bytes, they'll be automatically upgraded to ints anyway, so you can do an unsigned upgrade like so: 
    (int) somebyte & 0xFF

    That'll give you an int between 0-255. Casting back to byte also works as it should, i.e. the bits are correct, though if you print it out or look in a debugger it'll look "signed".

  • M L (unregistered) in reply to hacketihackhack
    hacketihackhack:
    Yeah it is rediciolus. Why not just base64-encode the thing and wrap it in a tag?

    But OTH gzipping it at transport level wouldn't make it THAT much bigger, since the byte tags are all the same.

    Base-64 would certainly be better, but only marginally. Since we are talking about web services here (Alex -- "web service" is two words!), then SwA or MTOM would be even better solutions.

  • me (unregistered)

    Base64 encoding anyone?

  • Vagmi (unregistered)

    WTF?? Why not Base[16|32|64]?

  • Dave (unregistered)

    Perhaps I'm missing something, but wouldn't CSV be a little less wasteful?

  • Matthew (unregistered) in reply to Edward Royce
    Edward Royce:
    Hmmmm.

    "<bytes>37</bytes>"

    Are you telling me that your library is wrapping a "<bytes>" + "</bytes>" tag pair around each and every singl byte of image data??

    Doesn't that blow up image sizes by 16? A 10k would become 160k. Isn't that a little ridiculous?

    Don't forget about the indentation and the CR/LF. What would be even cooler is if the bytes tag had attributes like type=signed.

  • Scott (unregistered) in reply to dkf
    dkf:
    Edward Royce:
    Are you telling me that your library is wrapping a "<bytes>" + "</bytes>" tag pair around each and every singl *byte* of image data??
    There is one way to fix this problem. Convert each of those to something like this (with namespaces omitted for brevity): 
    <bytes>
    <bit number="0" lsb="true">1</bit>
    <bit number="2">1</bit>
    <bit number="5">1</bit>
    <bit default="true">0</bit>
</bytes>

    By doing this, you eliminate the interoperability problem of just how to represent bytes and instead have something that is easy to interpret unambiguously every time!!

    That example wouldn't solve interoperability at all; you'd just change the signed vs unsigned problem in to an endianness problem!

  • bob hope (unregistered) in reply to xmlicious

    Hmmm... xml ... like a hot date with uml thurman...

  • ibcnu2much (unregistered)

    Turns out a major benefit to this representation is that it compresses MUCH better than the original.

  • EvilB2k (unregistered) in reply to cthulhu

    Ehrm... Are you serious? Images are nowhere near suited for the XML code as you describe it. As stated before: your image size would explode this way... Images should always be stored in a binary format if you ask me.

  • EmperorsNewFileFormat (unregistered) in reply to EvilB2k
    EvilB2k:
    Ehrm... Are you serious? Images are nowhere near suited for the XML code as you describe it. As stated before: your image size would explode this way... Images should always be stored in a binary format if you ask me.
    Binary file formats are so twentieth century. You need to move with the times.
  • IByte (unregistered) in reply to Edward Royce
    Edward Royce:
    [...] Isn't that a little ridiculous?
    If it weren't, would it have ended up on this site?
  • (cs) in reply to xmlicious
    xmlicious:
    XML is like violence: if it doesn't solve your problem, you're not using enough of it.
    Lol.

    XML isn't really even a language, just a specification of how you're supposed to write your own language.

  • Robert (unregistered) in reply to real_aardvark

    Errm, that isn't a PNG file (in Matt's example) that's a PDF file. I hope it's an uncompressed PDF then we might get upto a gigabyte per page then.

  • dPgn (unregistered) in reply to ljj116
    ljj116:
    The real WTF is that the <bytes> tag only contains a single byte....it should be <byte>. </rants>

    In C#/.NET if you have a property called "bytes" (with lower case first letter, against convention), which of type byte[] that is the default way it is serialized by the System.XML.Serialization.

    Of course, you should apparently NOT use the default behavior, but add a property such as string Base64Bytes that does the necessary conversion, and add [XmlIgnore] attribute to the raw byte array.

    XML serialization is my favorite feature in .NET (time saver in its own league), and it really hurts me to see it used in such a horrible way.

  • (cs) in reply to Scott
    Scott:
    That example wouldn't solve interoperability at all; you'd just change the signed vs unsigned problem in to an endianness problem!
    You're wrong there, you know. I remembered to have an attribute that allows the generator to specify what the endianness of the byte is. What's better is that you can change it on a per-byte basis, as this means that you're prepared for unambiguously communicating data that is composed from sources with different endiannesses. It also trivially adapts itself to dealing with machines where there are a different number of bits per byte, and would be also simple to extend to passing non-binary digits, even qubits (assuming a suitable representation in the first place; I'll leave that to the W3C), though at that point it would probably be a good idea to put the different digit representations into elements from different namespaces with xsi:type attributes to make it all hang together. Then we'd have perfect interoperability and an eternally comprehensible data representation; a true Rosetta Stone for the modern era, and what could be better than that for ensuring that the needs of the Enterprise are met going forwards into the decades to come?!
  • Robert (unregistered)

    The real WTF is that the spec says they are right!

    http://www.w3.org/TR/xmlschema-2/#byte

    the real wtf the real wtf the real wtf the real wtf the real wtf the real wtf the real wtf

  • Oh, enterprise (unregistered)

    That's clearly a professional enterprise-ready mission-critical turnkey five-nines HA business solution.

  • Derekwaisy (unregistered)
    Comment held for moderation.
  • Jimmyanten (unregistered)
    Comment held for moderation.

Leave a comment on “Oh, XML”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article