You are currently browsing comments. If you would like to return to the full story, you can read the full entry here: “I Hate You More Then Ever XML”.
Subscribe to Updates
CRT on Twitter
- CRTweet: RT @lukew: design principles for connected homes: http://t.co/kUiTZxfzYu my notes from @clurr talk at #uxlx
- CRTweet: RT @utahREpro: Want to be a beta tester for NAR REach? Sign up for the Insight Panel today! #NARmidyear http://t.co/DC2x5wimrR
- CRTweet: RT @narREach: Come to the 2nd demo day @Workface @LumentusSocial @getplanwise @reach150 @treater @updater @bombbomb. Will be at the expo ha…
I had no idea there were alternatives to XML, thanks for the info. More importantly, thanks for the roll your own comic link :p
i assume you’ve seen this too in your recent research http://code.google.com/apis/protocolbuffers/
XML’s infinite extensibility is what makes it a blessing and a curse. Sure, XSD sucks, but so does every other generic data definition language out there. Try DTD or RELAX NG if you’re really up for a fight.
I, too, am a big fan of JSON, but it pays for its lightweight nature at the expense strict typing, which is a dealbreaker in most data exchange scenarios.
When it comes to *structured* data, there really is no viable alternative at the moment, IMHO. YAML is okay, but equally lacks type-definition (AFAIK) and looks too much like a COBOL/Python mashup to be friendly to the 3rd gen language folks like myself.
… and there’s always our friend ANTLR. I love the idea, but haven’t had much success beyond the basics. I think there’s too high a learning curve for its niche/kitsch value that the average working stiff doesn’t have the time conquer.
I love/hate XML, too.
-Matt
@jp –
It’s time to coin YASF (Yet Another Serialization Format). First Facebook’s “Thrift”, now the not-very-different-but-with-a-far-lamer-name: “Protocol Buffers”.
Each of them *does* solve the problem of datatyping and terseness for messaging formats, but why do they have to go “the extra mile” and provide a crap RPC interface? Why can’t we get out of the 90s?
-Matt
I think protocol buffer is interesting (name could use some improvement). I personally think that writing a grammer has about the same difficulty as writing an XSD, but what I really want people do think about the tool they are using.
As to JSON, if typing being there is a problem, you could just make everything a string. Then it won’t matter, same with YAML. And if you use Kwalify you can make a schema if you need validation. I also know that YAML has some features that JSON doesn’t that might allow it to be used in more complex cases.
XML has it’s place, but I don’t think it’s a good idea for every. At one of my previous companies I had to parse GB sized files that were XML representations of emails. Why not use mbox format? Would have been much smaller and there are tools out that that already handle mbox.
Relax NG is an alternative to XSD, and has a non-XML grammar (Relax Compact).
It’s a pleasant alternative to XSD when XML is the correct document standard to start with.
My interest is in EDI where CSV is stubornly popular. After 10 years XML still hasn\’t replaced message definitions and standards that are 30 years old.
http://myediblog.blogspot.com/2008/07/alternative-edi-formats-part-i-csv-json.html
JSON can learn from Protocol Buffers, but I\’m convinced it can be better
http://myediblog.blogspot.com/2008/07/alternative-edi-formats-part-ii-json.html
YAMl does need a schema definition language. Encoding nuetral would be ideal – it might server to even go back and look at ASN.1 – I wonder if XML encoding rules could be written for ASN.1?
Ideally – a YAML-like syntax that was encoding neutral would be ideal. Looking at ASN.1 as a example – having a varitey of well definited types that are then later bound to the encoding rules would seem to work.