- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Diego - find Dora and use the MAP!
Admin
How about this: <response><hdr>[CDATA[field|field|field]]</hdr><data>[CDATA[John|Hancock|123rd Avenue]]</data>
The possibilities are endless!
Admin
Admin
Much much win in this comment!
Admin
I just hope Marlene Ruth is fictionalized. Otherwise, that's probably enough information for somebody to steal her identity.
Admin
How can we be sure that's well-formed XML? At least it's unlikely that any of the columns will be named <& ...
Admin
Awww, I was expecting you to say that, sure, they accepted XML requests! The format is:
Admin
Looks to me like that output was somebody's attempt to simulate CSV with XML. And by the way, wouldn't CSV output be much simpler in a case like this:
It would be a whole lot simpler to parse than XML, take less bandwidth, and eliminate whole categories of possible errors to check for (missing tags, mis-spelled tags, extra tags, improper nesting, etc etc).
I fail to understand the fascination with XML. Yes, there are cases where it's useful, but it seems to me that they are a very tiny number of cases.
Admin
Overheard during the vendor's design meeting: Lead Dev: We should begin defining the schema for the web service project.
Dev 1: Here's my list of fields that we currently transfer to the client. These should be represented in the schema.
Dev 2: But what if we need to add a new field for some reason, like we did for the Omega project last month?
Lead Dev: Well isn't XML extensible in fashion?
Dev 2: We could design the schema to be extensible.
Dev 1: <rolls eyes>
Dev 2: If we separate the list of fields from the values we don't have to change the schema ever and can be backwards compatible!
Dev 1: Aren't we missing the point of transferring this in using XML. Couldn't we use different name spaces for other features like Omega?
Lead Dev: The clients are going to have to re-write their code to use the new feature anyway. This will take less of our time to implement the changes and focus more on our data processing. Great work Dev 2.
Admin
Man, you do not understand the concept behind that, it is easy to transform it to HTML
See the following algorithm
remove first line change <result> to
and </result> tochange <fields> to and </fields> to
change <field> to and </field> to
change <data> to and </data> to
change <row> to and </row> to
change <value> to and </value> to
And that's it!!! and HTML returned output!!!
Admin
The whole point of high-level languages is to trade away some measure of raw efficiency and in return receive the ability to be able to develop software faster and more easily, and end up with something that is more maintainable.
Almost no one works with raw TCP/IP anymore. Similarly, almost no one should have to work with archaic fixed-width-field formats anymore. The comparatively minuscule performance benefit is nothing compared to the headache of having to use them all the time.
In any case, because virtually everyone except mainframe programmers relegated FWF to the scrap heap of history decades ago, the (inconsequential) performance benefits are going to be negated at the interface between the cobwebby old FWF format and the modern world.
FWIW, I've done development in everything from assembly to Java and C# for almost twenty years, and I've never had the need (or the desire) to mount an expedition into the Indiana Jones-esque ancient ruins of fixed-width fields.
Admin
Though even so I will agree that it is somewhat over-used.
Admin
What an interesting perspective of why this might have been done this way.
Friends, I think we found the lead developer for the vendor!
Admin
Admin
That's Apple's P-List format. It's the blockheaded Apple equivalent to Microsoft's .NET config files. (App.config, Web.config, machine.config, etc.)
You can find .plist files all over the place in MacOS X. iTunes, iPhoto, and Address Book (and probably others) all use that format for their databases. The iPod uses a copy of the iTunes one. The LaunchDaemon uses it to define background process startup (it's the recommended way of getting things like Apache HTTPD or PostgreSQL running on boot-up without a logged-in user). And I'd bet good money about eleventy hojillion other things use it now, just because it's built into the system libraries.
The idea of the P-List structure is to make something that seems to be equivalent to PHP's "arrays". If you've ever had the misfortune of working with PHP, you've used its arrays. They're actually kinda neat. But they're not arrays, they're hashmaps. The key must be a concrete value type (in PHP, that means int, float, string, or boolean). The value can be anything, including another "array". You end up with a flexible, nestable structure that, to the untrained noob, is OMGPONIES wonderful!!1!one!1! How Apple's otherwise professional software gurus thought this was good as an XML structure is anybody's guess.
But, hey, at least you can quickly turn your iTunes installation into a PHP-driven music repository. (Yes, I've done that, but I only allowed access from the LAN.)
Admin
Too much kids TV for you
Admin
aww, crap, this is exactly the kind of thing I'm working on right now. Not the XML, the fixed width concatenated strings that will shit a brick if any character is out of place...
:(
Admin
Admin
So, to sum-up with an analogy, you're saying we should still be using candles and lanterns because there's no risk of electrical fires.
Admin
Using XML to describe data as it if were a table instead of a collection of documents. It makes it not amenable to most XML validation and translation tools.
It is not a big WTF, but it is still one. Proper alternatives for representing XML could be either of the following (and their combination):
<?xml version="1.0" encoding="iso-8859-1" ?> <result> <person> <first_name value="John"/> <last_name value="Doe"/> <mother_maiden_name="Jane"/> <dob value="1973-02-24 00:00:00"/> </person> ... or like this ... <person first_name="John" last_name="Doe" mother_maiden_name="Jane" dob="1973-02-24 00:00:00"/> </result/>Also, you could make certain attributes as optional (.ie. mother's maiden name) so for those records that don't have, they are simply omitted:
<person first_name="John" last_name="Doe" <span style="color:red;">mother_maiden_name="Jane" dob="1973-02-24 00:00:00"/> <person first_name="Michael" last_name="Corvinus" dob="1973-02-24 00:00:00"/> </result/>When pushing and pulling thousands (or more) of such records over the wire per minute, such little things begin to matter.
Using XML as done in the feature WTF is usually a no-no. You end up having to write your own custom parsers, validators and transformers. Which you really don't need to when you already have validating parsers already written for you (so long as your XML are true collection of documents and not a simulated record set with an RDBM-inspired associated table meta data.)
Admin
Their benefit, at least it seemed consistent and readable. I had to deal with a poorly written RPC-over-XML spawn from hell that looked like this:
^^^ Notice above that in one request, the parameter is known as "email", but in another one, it is "e_mail". You'd find the same permutation-oriented malarkey with parameters and attributes all over the place with no discernible pattern.
Return types were even worse:
The account_x_transaction_amount_y is no typo btw.
Admin
FYI, TCP/IP is NOT fixed-width, it is stream with arbitrary data structure
Admin
There might be a way to salvage the way that particular xml was created. You see, XML elements have limitations in the way they can be named; maybe that arrangement was planned so you can actually name the output parameter names in any way you like (accents, whitespace, special chars) instead of MOTHERS_FRIGGIN_MAIDEN_NAME ...
Admin
Look what you've done, now someone's gone and stolen my identity!
Admin
Take a look at RPG sometime.
Admin
You shouldn't be doing XML with the latter method. It's not proper XML. Tag properties are for metadata, not data. Data should be encapsulated in its own element tag. Tag properties are almost never used in XML because it's typically intended for data interchange. Something like a checksum field would be appropriate, though, and might make sense if your element were (for example) Base 64 encoded images.
However, if wire speed is truly your limiting factor, you probably shouldn't be arguing for changing from proper XML an improper but less verbose XML. You should be more concerned with load balancing across multiple servers and multiple lines. You don't fix the fact that you're overloading your shipping containers by switching from flour sacks to teabags. You just buy more containers.
Admin
Both IP and TCP contain fixed width, binary fields. As are many other core protocols (HTTP and SMTP are not core protocols BTW). On the inside of a TCP stream, you're free to put any garbage you like of course.
And not everything TCP/IP is a stream. UDP and IP itself are datagram based for example.
Admin
WHOOSH
Admin
About ten years ago I got the XML religion and decided to use it as much as possible while implementing a web-based order processing system. Bottom line: ALL objects stored ALL of their INTERNAL data as XML, and data transmission between objects was accomplished by passing around pieces of each object's DOM tree.
Yes, packaging an object's internal data into strings (well, a DOM tree of strings) and requiring all objects to conform to one standard data schema and have full knowledge of all other objects' internal data representations -- all in the name of "XML!!!" -- was definitely a great idea... And I did it at the strong urging of some folks on an XML mailing list who thought it was an awesome idea...
Admin
Just because someone can implement a web service doesn't mean they're otherwise competent.
Admin
FWIW, these files may also appear as ‘plain’ text:
{ "452" = { "Track ID" = 452; "Name" = "Little Monk"; "Artist" = "Barenberg, Russ"; … }; … };Which is… somewhat nice.Admin
You should really go read something about network protocols. Nobody case what buffers and implementations inside TCP protocol, because for applications it is transparent stream.
And UDP has nothing to do with TCP
Admin
Admin
It makes me both sad and annoyed when I see things like that because the only way we have of dealing with crap like this is to vote with our wallets.
I read the stories here and I really wonder how some of these outfits are still in business. Is it that we, as an industry, are bad at writing CBAs or is it that there are a lot of managers who don't care about the bottom line?
B
Admin
Not to mention, bloated.
I guess nobody cares about bloat across today's networks, though...
Perhaps for a web service where the data is sent in small transactional chunks.
Even when the XML is well laid out, validating schema supplied/given, it still leaves a bad taste in my mouth when the volume of data is obnoxiously large.
Admin
Pretty piss-poor acceptance of a bad idea with our imaginary lead developer here... But hey, it happens. (too often...)
I think it's a great idea to have it be readily extensible. If the handshake is on an agree-upon format with the customer, AXSD "tries" to make this a reality. If you happen to be the one making the format and the data you are spitting out is almost analogous to the tables containing the data, there is no reason to not automate as much of it as possible.
Admin
Recently, when I started porting software to MacOS for the first time, .plist files were one of the first things I ran across. My initial reaction was "maybe I don't need this to run on a Mac after all." Luckily, things didn't get tooooo much worse.
Really? It seems this would make it harder. It's trivially easy to usefully load sane XML into a PHP structure. With .plist it seems you'd have write your own to parser that makes keys and values out of adjacent elements. Or am I missing something?
Admin
Actually, a certain "Enterprise" Application Integration software (whose name begins with a "T" and ends in a "IBCO"), don't know which version, has the healthy habit of parsing XML by field position.
meaning:
<xml> <field1>value1</field1> <field2>value2</field2> <field3>value3</field3> </xml>will fuck up if it's sent in a different order:
<xml> <field3>value3</field3> <field2>value2</field2> <field1>value1</field1> </xml>"Not out fault, you're the ones who should always send the fields in the same order!"
Oh really? What about if I told you our BEAUTIFUL (sarcasm warning) CRM software has no way of ordering the fields? Or better yet, it has a "preferred order" setting which aparently does nothing?
And to top it all up, each time the Web Service is recompiled, the fields get scrambled in a new order! Sweet!
Do any of these count as WTF's? :)
If not, how about the Ultra-Mega-Givemeallyou'vegot Web Service, which can generate anything from 50kb to 500kb (depending on the client) of data? Which is then sent directly to the client's web browser? At the cost of 2+ minutes of "waiting"? (also known as an "Experience Improver"... oh wait, it's the other way around! crap!)
And since I'm in such a good mood (last one, promise) how about a fixed-width CSV file with... variable width fields... god! Who the hell comes up with these things?? How twisted must your mind be not to notice you're generating a USELESS piece of crap??
Admin
Hmmm, I'm gonna have to disagree with you on this one.
One thing for certain is that there is no such well-defined thing as "proper XML". We have to acknowledge that we only have definitions of well-formed xml documentsthat might also be valid xml documents. Those are the only two things we can say (well structured and validity.) And we can only say that for XML documents, not for XML itself.
Their definitions are very precise, are defined wrt to xml documents (not just xml), and don't make any mention as of what to use elements and attributes for.
Everything else are just suggestions and practices that are best for specific situations, subjects to design decisions.
As for proper xml usage that is a matter of style, a very important issue, I agree with you. However those are domain-dependent. There is no consensus or agreement as of whether, when and how to use structures/tag or attributes.
The only things we have are guidelines, and most of those guidelines are of the form use attributes for data that is atomic or non-extensible; use tags otherwise. And we go back again to this chicken-and-egg situation. Atomicity and extensibility are domain-specific.
I can easily model and argue with validity that a person record is structured and can be extended (ergo in a tag) with constituents that are atomic and non-extensible (dob, first name and last name.) Without knowing anything about the context in which such a thing is to be used, there is nothing inherently wrong in this model, specially if XML is just for data transfer and not as its primary form of storage.
I'm also sure that there are other problem domains in which, yes, this would not be appropriate (or not the most appropriate) thing to do. And that shows that this is a guideline whose applicability is ultimately a design decision for a particular domain.
Matter of style, matter of domain. See above. I'm certain that you can find a scenario where the model above is not just suitable but wrong. For example, I could see an argument for not storing first and last names as attributes (specially given that names from other cultures can be constructs.) In that context, then you are on the right (so long as you realize it is about the context, and not about a religious rule about attributes and tags that admits no design compromise.)
The fact is that these are more religious questions rather that technical decisions. Whether one uses attributes for data or meta data is ultimately dependent on the architectural and design decision of what data and meta data is and whether they can/should/most be represented by the same (or different) means.
As long as the usage is consistent, the cons are well-understood and the model actually makes sense, it is pretty much fair game.
There is no such defined thing as a proper XML, at least not in the way you are arguing here (see above.)
Well, for starters, the comment was made in jest, but if we want to analyze it, let's do it. When all is equal, I agree with you in throwing more hardware to the problem (provided the solution is architected in a way that is scalable with the additional hardware.)
Very often either you don't have that, or it happens to be cheaper to change the format. For a nail, a hammer. For a screw...
Assuming you do a good study of the problem and you are aware of the ensuing trade-offs, you, as a designer, programmer and/or architect, and you have the freedom (or the relative low cost) to do so, you are free to change the format (either by shaving tags into attributes, removing trailing spaces, changing it to JSON or Google's Protocols Buffers or whatever), specially if it is only for dumb data transfer.
I'm sure there will be people that disagree on this. That's life. YMMV.
Admin
I dunno, that last bit looks an awful lot like a serialized System.Data.DataSet.
Oh wait, yeah, I don't think you're supposed to expose those at the end of a web service.
CAPTCHA - genitus - Intelligent Privates?
Admin
We use the later form all the time where I work. It works just fine.
Admin
Admin
I think it is a "proprietary Transmission Control Protocol protocol".
Filled under: Department of Redundancy dept.
Admin
The fixed width shenanigans speaks of a programmer who is only familiar with parsing binary file formats being asked to create a format for plain text.
Admin
The part that always scares me about XML is this paragraph in MSDN about the .NET XmlSerializer class:
Admin
Admin
CSV is not easier to parse than XML. Just try to open a CSV file with Excel and find that it expects semicolons instead of commas. And how do you escape a comma/semicolon within fields? Do you use single or double-quote characters? And how do you escape those? Say, would that be an ANSI file or CP1251?
With XML, all you have to do is use your friendly neighborhood XML parser and hey presto.
XML has its clusterfucks (such as XSD, which negates the whole 'extensible' idea and is context insensitive) and you can argue a number of technologies which would be better to use in different circumstances (ASN.1 FTW), but CSV is almost always the worst possible choice.
Admin
Easily fixed with some XSLT. In fact, I wrote that exact XSL transformation just a month or two ago.
And now I have two problems.
Admin
I have seen the converse of this at a previous company. Their webservice was a servlet that you pumped xml to. Note that no xsd's for this xml were ever conceived. In stead inegrators were always supplied with an xml example. Another system of theirs actually HAD a webservice. Similar to the stories examples, 1 param that took an xml blob. Again no xsd's. FML
Admin
So the vendor is a little clueless, been there done that!
It's nothing that can't be solved by introducing level of abstraction between that interface and the rest of your code. Then you can simply redo the implementation of that interface later if the vendor suddenly grew a brain and made something better.
learning how to deal with things like this is all part of the job.