• sweavo (unregistered) in reply to Patrick
    Patrick:
    To sum up this dialogue: Rick: "Hey Terry, my dick's bigger." Terry: "No, mine is." Rick: "No, mine is."

    Can we make this comment sticky somehow?

  • (cs) in reply to pscs
    pscs:
    Ah, but the thing is that how often are those all needed?
    Ah, but the thing is that you're much better off not needing an available feature than needing one that's not available. Quite often you don't know what you need in advance. Requirements change.
    pscs:
    I'm not, in any way, saying I've seen all possible uses of XML, but I am saying that I believe it's vastly overused. ISTM that some people see a data interchange problem, and immediately use XML without even considering alternatives. That is what I don't like. To me XML should be the last resort because it's so verbose and complex to parse.
    Disk space and communication bandwidth is bizarrely cheap these days. In the vast majority of all apps, they don't matter. And for parsing XML you have a choice of commercial and open source parsers (on more platforms than any serious contender) that are no more difficult to use than those for other formats, and far more optimzed and stable than any homegrown one.

    Using the best tool for every job is NOT desirable when it means you end up having to buy and learn 50 tools instead of one. Especially when your "tools" are used in communication with other people and you can only communicate with people that use the same one you do.

    XML is the Swiss army knife of communication formats. Its overuse is not so much a case of "if all you have is a hammer, everything looks like a nail", but a case of "if you have a tool that does nearly everything, nothing forces you to consider using anything else".

  • Tei (unregistered)

    People still fail to understand why we have XML, and is soo important nowdays.

    Is not because is good. Or better, than XYZ.

    XYZ can be faster, and more lightweight than XML for task JKL.

    There are zillions of XYZ tecnologies that are better than XML. And this why we use XML. Because with only ONE technology we can do a wide range of stuff.

    This mean a huge profit reutilization of knogment and tools.

    People that use different tecnologies for every different problem have to manage a giganteous set of different stuff. Where a profound knogment of XML will be more usefull.

  • 8879Factor (unregistered) in reply to gremlin
    gremlin:
    Endianness is about converting between numbers bigger than one byte, and bytes.

    A hex dump displays one byte at a time. There is no endianness involved.

    Every hex digit represents a nybble, not a byte. Eighteen can be represented as 12 (big endian) or 21 (little endian).

    All reg editors I've ever used are big endian for nybbles.

  • pok (unregistered) in reply to Mcoder
    Mcoder:
    Well, ok. Now we have a true WTF. If the info didn't reach you yet, XML is usefull because you can get an universal parser and deal with it in a few minutes.

    Now, if you are able to write hierarchical parsers in a few minutes, you can go without XML.

    No need, such a parser has been a part of my preferred programming language since the sixties, and central to its implementation. It's called (read).

  • (cs) in reply to Tei
    Tei:
    There are zillions of XYZ tecnologies that are better than XML. And this why we use XML. Because with only ONE technology we can do a wide range of stuff.

    OK, so based on that argument, why do we have C++, C#, Java etc. Lets just use JavaScript everywhere...

    OK, with JavaScript you can't do some things, but with XML you can't do some things either, like have efficient use of bandwidth, storage, CPU cycles. You'll say 'those are cheap nowadays' - but then in the next breath you'll complain about Vista...

  • Maarten (unregistered) in reply to gremlin
    gremlin:
    Zygo:
    iToad:
    A hex dump shows reality.

    OK, but is that a big-endian hex dump, or a little-endian hex dump?

    Endianness is about converting between numbers bigger than one byte, and bytes.

    A hex dump displays one byte at a time. There is no endianness involved.

    But how to interpret the hex dump? I guess endianness is involved after all.

  • (cs) in reply to pscs
    pscs:
    Tei:
    There are zillions of XYZ tecnologies that are better than XML. And this why we use XML. Because with only ONE technology we can do a wide range of stuff.

    OK, so based on that argument, why do we have C++, C#, Java etc. Lets just use JavaScript everywhere...

    Standardization on one language is less important for development because a development project typically stays within the same organization.

    But for communication formats, standardization is everything because building bridges between heterogenous systems and organizations is their very essence.

    Note that even with programming languages, there is a strong tendency to have a small number of "market leaders" that are used by the majority of projects and on which organizations standardize as much as practicable.

  • Hey (unregistered)

    The real wtf here is that they are using vista.

  • burned (unregistered) in reply to Welbog
    Welbog:
    gabba:
    "XMLSpy and IE both correct minor errors". Maybe this should have given Rick a clue as to how to proceed.
    Except then Rick would have to use a home-grown XML parser or, potentially worse, fudge the incoming XML with a front-page-worthy replace function that finds 's and replaces them with "s only in the right situations.
    I should image this is very common. I have in the company commons a class called "DeFuckIEXmlStream".
  • Thomas (unregistered) in reply to real_aardvark

    Add to this the fact that few developers seem to know that XML is actually encoded in the first place. &quot and the like..

  • Thomas (unregistered) in reply to real_aardvark
    real_aardvark:
    Zylon:
    Grovesy:
    The worrying thing is, I can't think of any xml library in any language that would generate some attribute values enclosed in ' and others in "

    Which can only mean they are hand crafting the xml... errk

    When the XML document is tiny and/or guaranteed to have a static structure, it's perfectly reasonable to decline involving a lumbering XML library.

    If the XML doc is guaranteed to be tiny and/or to have a static structure, it's even more reasonable to decline to involve XML in the first place.

    Add to this the fact that few developers seem to know that XML is actually encoded in the first place. &quot and the like..

  • (cs) in reply to Thomas
    Thomas:
    real_aardvark:
    Zylon:
    Grovesy:
    The worrying thing is, I can't think of any xml library in any language that would generate some attribute values enclosed in ' and others in "

    Which can only mean they are hand crafting the xml... errk

    When the XML document is tiny and/or guaranteed to have a static structure, it's perfectly reasonable to decline involving a lumbering XML library.

    If the XML doc is guaranteed to be tiny and/or to have a static structure, it's even more reasonable to decline to involve XML in the first place.

    Add to this the fact that few developers seem to know that XML is actually encoded in the first place. &quot and the like..

    Comes back to the point, that if your language of choice has a good xml library, use it! You will be guaranteed both a valid and consistently encoded document.

  • (cs) in reply to Justin Haygood

    Most people don't know what XML is...I had to work on a project where the client had purchased an XML data feed that they wanted integrated into their database. Great idea, except the feed wasn't actually XML at all. The data was marked up with tags that looked kinda like XML, but the file wouldn't even being to parse in Perl using expat. (Missing a root tag, they didn't escape special characters, etc.

    The 3rd party vendor refused to work and claimed we were being lazy, and the client took their side. I ended up having to write a script to preprocess the data feed from marked up gobbledy gook into real XML.

    I think in the future when I agree to work on projects like this where I have to work with other contractors, I'm going to put in the contract some technical terms, such as "XML data feed must be parseable with expat, or else this contract is null and void."

  • (cs) in reply to brazzy
    brazzy:
    But for communication formats, standardization is everything because building bridges between heterogenous systems and organizations is their very essence.

    Sort of, but not really...

    Eg, You have an address book program. I have a telephone dialing program written totally separately. Just by making them both support XML won't magically let them work together. Both sides need to know how data is named, how it is represented etc.

    There would need to be some intention by one side or the other or both to have them work together. Since that requirement is there, why not use a simpler, more efficient format (eg ASN.1 with BER) and make both programs half the size and twice as fast?

    I worked with 'tagged' data structures years before XML was even thought of, they were very similar to XML, and were sold to us on the same benefits that are used for XML nowadays. None of the suggested benefits (eg increased interoperability) existed (we could have got just as much interoperability from simpler solutions), and all the downsides were there (slow, clunky, verbose). Just the same as with XML.

    I can see the point of XML - but only for about 1% of the situations when it's actually used.

    Yes, I know you'll say 'it's what we know. The fact that it takes 10MB to store 1MB of data doesn't matter, disk space/memory is cheap. The fact that it takes 10 times as long to get at the data doesn't matter, CPU power is cheap'.

    That's fine, as long as you realise that - but don't complain at other things that are slow, inefficient, or CPU/memory hogs. If you want things to be done in the "best" way, XML usually isn't it.

  • (cs) in reply to pscs
    pscs:
    brazzy:
    But for communication formats, standardization is everything because building bridges between heterogenous systems and organizations is their very essence.

    Sort of, but not really...

    Eg, You have an address book program. I have a telephone dialing program written totally separately. Just by making them both support XML won't magically let them work together. Both sides need to know how data is named, how it is represented etc.

    There would need to be some intention by one side or the other or both to have them work together. Since that requirement is there, why not use a simpler, more efficient format (eg ASN.1 with BER) and make both programs half the size and twice as fast?

    I worked with 'tagged' data structures years before XML was even thought of, they were very similar to XML, and were sold to us on the same benefits that are used for XML nowadays. None of the suggested benefits (eg increased interoperability) existed (we could have got just as much interoperability from simpler solutions), and all the downsides were there (slow, clunky, verbose). Just the same as with XML.

    I can see the point of XML - but only for about 1% of the situations when it's actually used.

    Yes, I know you'll say 'it's what we know. The fact that it takes 10MB to store 1MB of data doesn't matter, disk space/memory is cheap. The fact that it takes 10 times as long to get at the data doesn't matter, CPU power is cheap'.

    That's fine, as long as you realise that - but don't complain at other things that are slow, inefficient, or CPU/memory hogs. If you want things to be done in the "best" way, XML usually isn't it.

    The way I see it… the following are good applications for xml…

    Two systems, in separate locations without a hard link between the two, written in different technologies running on different platforms need to communicate with each other. The cost of implementation needs to be done quickly and cheaply – Answer: SOAP (Both .Net and Java for example have code generation tools for producing proxies. Mapping between objects and xml is handled for you, so is verification that the documents conform to the specification).

    Rapid development of an app to import data… Had to do this many times, you throw a rough spec at a competent supplier; they throw back xml documents… Never exactly how you asked it to be, though as a consumer intelligent enough to work out what the data is by opening it up in XML spy. Using XPath can pull out and process values very quickly and map to a database. Last time I had to this, the xml files were 100mb or so… But as we were also importing several gig of images and video clips that all needed to be resized and processed , so the verbosity of XML really wasn’t an issue here. No vendor could seem to conform to the spec, so XML was perfect as we could use XSLT to convert there document format into our supported format, implement an XSD for each supplier so we know if they change their format in any way.

    Configuration: Can read the document on app start-up and, cache the values in the app. Not many reads on the file past start-up.

    XML also has a good application in messaging systems where there is a diverse set of technologies… (reading XML messages of IBM MQ outputed by an ancient COBOL system with a custom written xml library written in Assembler was a hoot). Though in most systems I’ve seen a proprietary lightweight format would have done the job better

  • (cs) in reply to Anon
    Anon:
    Choose one: Windows INI files, or Java properties files - basically the same solution, but both pre-date XML, and both have actual error recovery if you screw up a setting.

    Oh, right. INI files have NO error handling (don't even generate errors at all), and the solution to not using XML is to add a language specific (Java) properties file.

    Did you give any thought to your answer before posting it?

    Anon:
    Wait, seriously, they use XML for serialization?! I'll say JSON, but you really want a binary solution for something like that.

    Again, something language specific to solve a general purpose problem?

    Let me guess... You only know Java, right?

    Anon:
    JSON would work.

    Java?

    Anon:
    JSON again.

    Java?

    Anon:
    Who knows? Depends on the specifics. I'll go with JSON for no good reason.

    Java?

    Anon:
    For almost any real use of XML, JSON provides a simpler syntax for encoding the same data in a less verbose and less error-prone manner. It's a far better "platform agnostic" format, although it has some problems itself. (Mostly dealing with character encodings, something XML never really solved in any case.)

    Java?

    Explain how JSON works again if you happen to use something other than Java. Explain how a language-specific toolkit is better than a text-based file format. Explain why I would want to use something that ties me to a specific language, which is also a language that I don't care to work in. (I do primarily Win32 development, and prefer to use a better language for that platform.)

    XML is fine if you use it for the purpose for which it was designed, the transfer of data between disparate systems. We use it, for example, to move data from our local Windows-based office network to our corporate accounting system (Solaris). It allows easy validation both here prior to sending it, and at their end prior to processing it. A good XSD allows even data type and size validation, as well as required elements. And I use it from applications written in the language we prefer to work in, and they use it from their systems written in Java or C++.

    I guess if the only thing you know is Java, it's hard to see anything else. (You're a good example of "taking a hammer to everything", apparently, because you can't seem to see any other tools. Perhaps you should expand your knowledge somewhat? Pull your head out of the Java sand, little ostrich, and spread your wings.)

  • Irony (unregistered) in reply to Anon

    You got it in one!

  • Irony (unregistered) in reply to Anon
    Anon:
    The real WTF is that anyone thought this was a WTF
    You got it in one! (forgot to quote in the last post :)
  • (cs) in reply to real_aardvark
    real_aardvark:
    The only possible reason to make a computer protocol human-readable is that it will be read by humans, not written by humans. And, as Terrence Parr argues so eloquently (and correctly), XML is a disastrous choice for a human-readable API.

    Wow. Until this post, I'd read all your others and thought that you were reasonably intelligent. I guess this post changes that impression.

    I work all the time with various types of EDI. The "industry standard" formats suck, bigtime. I can give you a perfect example.

    Here's a sample EDI (X12) order file:

    ISA+00+ +00+ +ZZ+SenderID +ZZ+ReceiverID +040430+0842+!+05012+000000001+1+P+:' GS+PO+SenderID+ReceiverID+20060308+182347+1+UN+05012' ST+850+12345' BEG+00+SA+ABC123456XYZ++20040430' N1+1 +Nanonull, Inc.++123' N2+Michelle Butler' N3+119 Oakstreet Suite 4876' N4+Vereno+CA+29213' PO1++1++7.2+++42' PO3+1 +++7.2++1+US' PID+1++++Pizza Pepperoni' TXI+1 ++9' AMT+1+7.2' PO1++2++13.2+++105' PO3+1 +++6.6++2+US' PID+1++++Lasagne al Forno' TXI+1 ++9' AMT+1+13.2' PO1++1++7.5+++66' PO3+1 +++7.5++1+US' PID+1++++Chianti DOCG' TXI+1 ++18' AMT+1+7.5' SE+22+12345' GE+1+1' IEA+1+000000001'

    Here's the exact same file, in XML:

    <?xml version="1.0" encoding="UTF-8"?> <Order xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Order.xsd"> <Header> <Number>ABC123456XYZ</Number> <Received>2004-04-30T17:42:00-09:00</Received> </Header> <Customer> <Number>123</Number> <ContactName>Michelle Butler</ContactName> <CompanyName>Nanonull, Inc.</CompanyName>
    <Street>119 Oakstreet Suite 4876</Street> <City>Vereno</City> <ZIP>29213</ZIP> <State>CA</State>
    </Customer> <LineItems> <LineItem> <Article> <Number>42</Number> <Name>Pizza Pepperoni</Name> <SinglePrice>7.2</SinglePrice> <Amount>1</Amount> <Price>7.2</Price> <Tax>0.648</Tax> </Article> </LineItem> <LineItem> <Article> <Number>105</Number> <Name>Lasagne al Forno</Name> <SinglePrice>6.6</SinglePrice> <Amount>2</Amount> <Price>13.2</Price> <Tax>1.188</Tax> </Article> </LineItem> <LineItem> <Article> <Number>66</Number> <Name>Chianti DOCG</Name> <SinglePrice>7.5</SinglePrice> <Amount>1</Amount> <Price>7.5</Price> <Tax>1.35</Tax> </Article> </LineItem> </LineItems> </Order>

    Which would you prefer to troubleshoot during system development?

    If you have half a brain, there's not even a need to hesitate before answering. XML is obviously a better solution.

    real_aardvark:
    I think that, given the assumed universality of the protocol, it is perfectly reasonable to suggest that Anon might be significantly smarter than a substantial proportion thereof. That's the thing about universality.

    I imagine that Anon, like me, would grit his teeth and use XML in many situations, because it's just there. Which doesn't make it "appropriate." And it is true: XML zealots do tend to fly off the handle at even mild criticism of their ugly, warty little baby.

    Ok. So Anon's Java solution is the only workable one. Right. And being tied down to a specific language and implementation is smart. Right.

    What color is the sky in your world? Oh, that's right. You're just a real_aardvark.

    real_aardvark:
    Priceless.

    Right you are.

    real_aardvark:
    I hardly think that this is in the spirit of the alarmingly verbose XML. What's a few megabytes between friends? Can you say "ludicrous premature optimisation?"

    Right. I worry about that extra few bytes on my 250GB drive, or on the 2TB NAS device.

    The two samples I posted are 629 bytes and 1.2K in size, respectively. I'll take the larger file any day for readability when tracking down problems, thank you. Having my head up my ass just to be "cool" ain't my idea of fun. Apparently, it's yours.

    In today's world (where apparently you aren't), drives are bigger than floppy disks. My mother's new machine came with a 200GB drive, for Pete's sake! We're not talking about your little toy systems; we're talking about actual business-level machines that work with business related data.

    real_aardvark:
    Just as testers need developers as the essential feed to their work-flow, so developers need morons in turn.

    And with this post, you show that you're keeping us developers supplied.

    real_aardvark:
    Imagine a world with a tragically short supply of morons. How would developers spend their time? (Open source, I know.) Who would fund our opulent existence? If morons could do simple programming jobs, we'd all be in deep shit.

    Does that mean you'll stop trying to do simple programming jobs now? You obviously haven't done anything non-simple yet, so there's still time for you to walk away.

    real_aardvark:
    Viva Los Morones!

    And self-celebration as well! Good for you, little boy!

    As I posted above to Anon, XML is great when used for the purpose for which it was intended, the transfer of data across various platforms and systems. It's cross-platform (OSs), CPU's, and development languages, as opposed to JSON. That means that people other than you script kiddies can use it. You know, those of us with more tools in the toolbox than Java?

    Do me a favor. If you ever apply for a job in upstate NY, make sure that "real_aardvark" is mentioned somewhere in your resume. That way, I can just quickly throw it in the round file bucket and move on.

  • (cs) in reply to KenW
    KenW:
    Anon:
    Choose one: Windows INI files, or Java properties files - basically the same solution, but both pre-date XML, and both have actual error recovery if you screw up a setting.

    Oh, right. INI files have NO error handling (don't even generate errors at all)

    Actually INI files need far less error handling than XML...

    You can't go much wrong with

    [WindowSetting] X=100 Y=100 Width=200 Height=75

    You can set defaults for missing values, and that's about all you need..

    You're more likely to get errors with an XML equivalent..

    KenW:
    Anon:
    JSON would work.

    Java?

    So, you don't know what JSON is either then?

    JSON is JavaScript Object Notation. Nothing at all to do with Java. You could write a JSON generator/parser very simply in pretty much any language.

    It is more limited than XML. JSON is a way to describe data structures. So JSON doesn't have the concept of DTD or schemas, but if you don't use those, then JSON might be better for you than XML. You won't need to add nearly 200k to the size of your program just to parse the configuration file..

  • (cs) in reply to KenW
    KenWI:
    guess if the only thing you know is Java, it's hard to see anything else. (You're a good example of "taking a hammer to everything", apparently, because you can't seem to see any other tools. Perhaps you should expand your knowledge somewhat? Pull your head out of the Java sand, little ostrich, and spread your wings.)

    Isn't JSON a subset of YAML?, I didn't think JSON or YAML had anything to do with Java?? (Had to work with YAML once)

    If JSON is anything like YAML, for the job of data interchange is much nicer and simpler than XML as YAML allows for a kind or relation representation of data, unlike XML (and i think JSON) which only allow a hierarchical representation.

    My view of JSON is, nicer than XML for job of data interchange.. Shame the libraries aren't to widespread in the .net world (where I mostly develop in)

    e.g. (staight from Wikipedia)

     {
    "firstName": "John",
    "lastName": "Smith",
    "address": {
        "streetAddress": "21 2nd Street",
        "city": "New York",
        "state": "NY",
        "postalCode": 10021
    },
    "phoneNumbers": [
        "212 732-1234",
        "646 123-4567"
    ]
}

    Addendum (2007-11-30 12:30):

    KenWI:
    guess if the only thing you know is Java, it's hard to see anything else. (You're a good example of "taking a hammer to everything", apparently, because you can't seem to see any other tools. Perhaps you should expand your knowledge somewhat? Pull your head out of the Java sand, little ostrich, and spread your wings.)

    Isn't JSON a subset of YAML?, I didn't think JSON or YAML had anything to do with Java?? (Had to work with YAML once)

    If JSON is anything like YAML, for the job of data interchange is much nicer and simpler than XML as YAML allows for a 'kind of' relational representation of data, unlike XML (and i think JSON) which only allow a hierarchical representation.

    My view of JSON is, nicer than XML for job of data interchange.. Shame the libraries aren't to widespread in the .net world (where I mostly develop in)

    e.g. (staight from Wikipedia)

     {
    "firstName": "John",
    "lastName": "Smith",
    "address": {
        "streetAddress": "21 2nd Street",
        "city": "New York",
        "state": "NY",
        "postalCode": 10021
    },
    "phoneNumbers": [
        "212 732-1234",
        "646 123-4567"
    ]
}
  • Anon (unregistered) in reply to KenW
    KenW:
    Oh, right. INI files have NO error handling (don't even generate errors at all), and the solution to not using XML is to add a language specific (Java) properties file.
    Uh, neither of those are language-specific. They're both plain-old text forms. Creating a parser in any language is easy enough - far easier than XML.

    It's just that the spec for Java properties files is well-defined, including the character encoding. Java happens to include API for reading and writing them, but it's simple enough that anything can use them.

    Did you give any thought to your answer before posting it?
    I can say the same to you:
    Again, something language specific to solve a general purpose problem?
    Serialization isn't exactly general purpose. Even so, JSON would work just as well as XML, with the added advantage of containing numeric and string types.
    Let me guess... You only know Java, right?
    And I'll cut out the rest because you repeat Java so much, even though I mentioned it once, for the Java properties file.

    Here's a hint: the S in JSON stands for "Script". It's JavaScript, which is a completely different language than Java.

    Even so, if you even bothered to look at the JSON spec (here: http://json.org/), you'd notice that JSON has parsers written for a huge number of languages. (Including 16 Java, 7 C#, 5 C++, and 4 C libraries.) My favorite would have to be the Prolog version, which is a great example of how simple and flexible JSON really is.

    And I'll also point out that, no, I'm not really suggesting that JSON is applicable to all tasks. But it's at least as applicable as XML is, with the benefit of being far less verbose and tons easier to parse.

    As for things like schemas and namespaces, there's no reason such features couldn't be defined much like they were for XML. There's just no standard.

  • (cs) in reply to Grovesy

    Ok I clicked edit to fix a typo... and the post got duplicated in on itself..

    once again the Real WTF is the forum software :)

  • LEo (unregistered) in reply to cavemanf16

    Unfortunately, I totally agree :-( Simply happens to often.

    CAPATCHA: pirates -bay :-)

  • tamosius (unregistered)

    I stuch in 1990's world.. using some IVR script, so I wasn't using a lot of XML, and JASON is new to me, so I guess, I'm looking at things with fresh eyes ;-)

    Let's forget adaptability of XML vs JASON arguments, and check only at the syntax (I got that this example from json.org/example.html):

    {"menu": { "id": "file", "value": "File", "popup": { "menuitem": [ {"value": "New", "onclick": "CreateNewDoc()"}, {"value": "Open", "onclick": "OpenDoc()"}, {"value": "Close", "onclick": "CloseDoc()"} ] } }}

    The same text expressed as XML:

    <menu id="file" value="File"> <popup> <menuitem value="New" onclick="CreateNewDoc()" /> <menuitem value="Open" onclick="OpenDoc()" /> <menuitem value="Close" onclick="CloseDoc()" /> </popup> </menu>

    If I'd have to trouble shoot, I'd pick JSON over XML any day of the week... why? because I guess any programmer is familiar well enough with c syntax style, so using curly brackets is quite natural, as well it's elegant and easy enough on your eyes.. But... who said world is fair? not always the best things win..

    P.S. go to the site JSON.org site and look at examples there - they are going to be indented properly

  • tamosius (unregistered)

    oy! sorry for mistakes in the previous post, you get the idea, I hope ;-)

  • (cs) in reply to Venda Killa
    Venda Killa:
    {Sound of the vendor's head hitting my desk}

    I like this one. Can we keep him?

  • JJ (unregistered) in reply to Shinobu
    Shinobu:
    WTF 1: insisting single quotes are not allowed WTF 2: insisting notepad replaces quotes The Real WTF™: using XML

    Interestingly, feed this to IE:

    clipped

    All correctly syntax-highlighted, mind you, so evidently it gets parsed correctly, but the resulting display is not valid XML even when we ignore the +/- thingies.

    Microsoft, secretly breaking standards since 1980.

  • Yann Vernier (unregistered) in reply to Nelle

    Oh, how I wish that Notepad would refrain from automated conversions... I had a lab task where we were instructed to use Notepad to edit some source code before compiling it with an ancient DOS compiler. The compilation failed with a nonsensical error. The problem was revealed using qbasic's editor - Notepad had inserted Byte Order Markers at the beginning of the file. This is a new Unicode focused feature automatically activated in Notepad from win2k or later, apparently.

  • sPh (unregistered)

    I have fought very similar fights with clients/3rd party vendors. I finally got my point across when I made them open up the the file in a hex editor and take a look at the actual hex values.

    For many of the packaged software products I have supported, tech support would come back to that request with "use of a hex editor is a billable task by the Custom Programming Group. Please contact your salesrep for a Custom Programming quote. Case closed WAD".

    sPh

  • (cs) in reply to Colyn
    Colyn:
    I have a similar XML story.

    We use a third-party vendor for certain kinds of data and I had requested that they send me a list of ids via HTTP request. They sent the ids as a comma separated list as the response:

    1,2,3,4,5,6,...

    I requested that they send it in XML instead. They changed the response to the following:

    <xml> <ids attr"1,2,3,4,5,6,..."> </xml>

    Gee thanks!!

    Reminds me of this article.

  • drobnox (unregistered) in reply to Tei

    knogment !!!

    what a great new word.

  • Someone (unregistered) in reply to KattMan
    KattMan:
    ender:
    OK, correct me if I'm wrong, but doesn't XML allow both single and double quotes to be used for attribute values?

    Actually, attribute values should be delimited by double quotes. It does not say that they should not be delimited by anything else. Because of this, parsers were written to handle both. Because some parsers handle both (like IE's) but the spec says double quotes, IE will convert the singles to doubles and happily churn along.

    http://www.w3.org/TR/xml/#sec-common-syn states:

    [10] AttValue ::= '"' ([^<&"] | Reference)* '"' | "'" ([^<&'] | Reference)* "'"

    So, it seems you are incorrect. Single quotes are OK for attributes. IE just chooses to display all attributes in double quotes.

  • Lukey (unregistered)

    real_aardvark, can you please respond to KenW ? Where's the popcorn? This is better than my wife's soap operas!

  • Tom (unregistered) in reply to atari
    The wtf is that they're using notepad on vista, right?

    Oh yes, it's clearly the operating system. If they were doing all this in Linux it'd be A-OK. Let your prejudices go. If Linux had a mass-market presence (or when it has one if you're optimistic/deluded), you'll find the principle of Stupide sans Frontieres applies.

  • Kirsten (unregistered)

    "automagically" ?

  • Dictionary (unregistered) in reply to Kirsten
    Kirsten:
    "automagically" ?

    automagically adv - incorrectly

  • Frixus (unregistered)

    The RealWTF(tm) is that they didn't just submit the file to http://validator.w3.org/, ending all discussion. That would have shown that the XML document is indeed valid, as several people have already pointed out.

  • (cs) in reply to Bejesus
    Bejesus:
    The cause is that Rick was ignorant of the standard. He seems to be making the usual basic error of thinking that XML just sorta looks like this a bit like HTML.
    Run that past me a little slower.
  • Simon O'Doherty (unregistered) in reply to Alun

    Please tell me your joking.

  • Simon O'Doherty (unregistered) in reply to Pap

    That isn't related. I had a quick look at that. What is happening is when you create a document for the first time it will save as ANSI. When you open the document it will attempt to read it in as UNICODE because the string combination is fooling notepad.

  • Simon O'Doherty (unregistered) in reply to Simon O'Doherty

    Ok I apologise, went and read up the spec. :/

  • Shill (unregistered) in reply to pscs
    pscs:
    brazzy:
    But for communication formats, standardization is everything because building bridges between heterogenous systems and organizations is their very essence.

    Sort of, but not really...

    Eg, You have an address book program. I have a telephone dialing program written totally separately. Just by making them both support XML won't magically let them work together. Both sides need to know how data is named, how it is represented etc.

    There would need to be some intention by one side or the other or both to have them work together. Since that requirement is there, why not use a simpler, more efficient format (eg ASN.1 with BER) and make both programs half the size and twice as fast?

    By using XML as the interface into my address book application, I am allowing for the potential for other applications (not just yours) to interoperate with mine with a minimum of fuss. Furthermore, if another app already uses XML, likely different from mine, XSL exists to bridge the gap. Also, the XML can be extended in the future without impacting existing applications.

  • Colyn (unregistered) in reply to BrownHornet

    Hey, that is my story....I didn't realize they posted it. Cool!

  • Anon (unregistered) in reply to Shill
    Shill:
    By using XML as the interface into my address book application, I am allowing for the potential for other applications (not just yours) to interoperate with mine with a minimum of fuss. Furthermore, if another app already uses XML, likely different from mine, XSL exists to bridge the gap. Also, the XML can be extended in the future without impacting existing applications.
    Not even slightly true. Yes, theoretically it should be true, but XSLT is unfortunately frequently inadequate for translating from one format to another.

    Here's a simple example: one application takes dates in the format "2007-12-02", the other demands "Dec 2 2007". Go ahead and translate that using XSLT.

    Of course you could suggest that they should have done something like:

    <date year="2007" month="12" day="2"/>

    But translating that to:

    <Date year="2007" month="Dec" day="2"/>

    Is still a massive headache in XSLT, with the added benefit of being at the least possible.

    But you get the idea.

  • Synonymous Awkward (unregistered) in reply to Tei
    Tei:
    the concept of plant/text
    I shudder to think what it must be like where you work.

    New Support Ticket Priority: 1 Description of Problem: !!!URGENT!!! My desk pot plant won't open in emacs!!!

    real_aardvark:
    XML zealots do tend to fly off the handle at even mild criticism of their ugly, warty little baby.

    Priceless.

    While the anti-XML zealots fly off the handle at the thought that someone might actually use a piece of technology, even after they specifically instructed us not to do so.

    Both groups are whiny and irritating in equal measure, I say.

  • DreamWarrior (unregistered)

    This thread was priceless. Thanks for the great read. I forgot how absolutely hilarious XML vs. the world arguments were.

    All tools have a place, a versed practitioner knows when and where a tool is applicable. Wanton use of a tool is just as ignorant as total disregard for a tool's usefulness.

    I keep my opinion of XML in the "grey area". XML is good for some things, not so good for others. If I want to fab up a quick and dirty format to communicate information between two parties then XML may be great. If I want to do that at 600 tps with a good clip of data...well, maybe I should start looking at something that won't blow the hardware budget.

    The problem with XML proponents is their tendency to market XML as the solution. They tend either to never admit or entirely ignore that XML has weaknesses. It is slow to process and it is bulky. You will, obviously, never see that in an XML marketing glossy. However, if this trade-off is worth it in your application for the benefit of pre-written, cross-platform, standardized tools to process, edit, and generally work with XML then by all means, leverage it.

    I feel, however, that the only real argument supporting XML is that it is textual. Otherwise, it is simply a method to encapsulte data. Being textual, has its pros and cons. On the plus side, it can be read and written by a human, with varying degress of complexity based on the document format, in simple editors. It also means that it need not worry about integer and floating point storage and byte order, which makes the standard easier to define and easier to implement. However, it carries performance and storage penalties. Despite this, the textuality of the format has made it successful.

    Further, any other arguments in support of XML are, IMO, due soley to its industry adoption and standardization. For example, the tool and feature set that XML has adorned is often argued as a benefit. However, cross-platform parsers and editors, XPATH, DB integration, etc would exist for any standardized, open, and embraced format (text or binary) that offered a similar mechanism to encapsulate data. However, to the best of my knowledge, another such format has yet to proliferate the industry. (Binary XML anyone?).

    Despite its drawbacks, though, XML has been embraced. Through the marketing machine it has gained industry acceptance and to convince that industry, which has spent billions marketing and pushing the format, to convert to something less bulky and faster would be very difficult. So, likely we're going to have to live with XML for a while.

    On the plus side, the hardware industry is happy to take your money to supply the horsepower to parse and store a verbose and clunky format :-). But, at least you can read and edit it with Notepad, LOL!

  • (cs) in reply to DreamWarrior
    DreamWarrior:
    This thread was priceless. Thanks for the great read. I forgot how absolutely hilarious XML vs. the world arguments were.

    Bravo to you, and this thread has been almost as funny as a google search for ``email code plz''.

    Here's a straw man we can all get a whack at: http://tools.ietf.org/html/rfc3252

  • DreamWarrior (unregistered) in reply to arty
    arty:
    DreamWarrior:
    This thread was priceless. Thanks for the great read. I forgot how absolutely hilarious XML vs. the world arguments were.

    Bravo to you, and this thread has been almost as funny as a google search for ``email code plz''.

    Here's a straw man we can all get a whack at: http://tools.ietf.org/html/rfc3252

    Actually, that was kind of funny. I quite liked the line, "the reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the wider deployment of IPv4 and the fact that implementing IPv6 as XML would have exceeded the 1500 byte Ethernet MTU."

    I remember at my previous job the senior architects came across a study that proved XML more compact than a chosen set of binary formats. They concluded that our binary formats were, therefore, ineffective transports and therefore we were to re-engineer all messaging through our 600+ tps real-time system to be XML.

Leave a comment on “Notepad Translation Error”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article