- From: Michael Mealling <michael@neonym.net>
- Date: 20 Feb 2003 07:47:20 -0500
- To: Elliotte Rusty Harold <elharo@metalab.unc.edu>
- Cc: "Noah Mendelsohn/Cambridge/IBM" <noah_mendelsohn@us.ibm.com>, www-tag@w3.org
On Thu, 2003-02-20 at 06:04, Elliotte Rusty Harold wrote: > At 3:06 PM -0500 2/19/03, Michael Mealling wrote: > >While not quite the proto-typical web services area, there are several > >IETF protocols that would like to use XML that also have these same > >characteristics. In several cases we have requirements that closely > >match DNS's 'network footprint' and server side scalability strengths. > > Then may I politely suggests that XML is a not a good fit for your > needs, and you should use something else? It sounds like the XML > everywhere meme has gone too far. I like XML for what it is good for > (and that's a lot of things), but let's not turn it into an Edsel. It > can't and shouldn't do everything. If you need fixed length fields, > binary representations, and so forth, then you need something other > than XML. We looked at just about everything we could find. ASN.1 had its typical problems with encapsulation of unkown data types. Most of the other were to simplistic since we had to deal with things such as limited use of namespaces, encodings, schemas, etc. In other words, to handle the applications we're after we would've ended up creating something almost exactly like XML 1.0 in a binary form, just not called XML. That would've been a rather silly thing to do given perfectly reasonable solutions that already exist. I find it much more productive to start with something that solves all of the required problems except one and fix that rather than throw out a perfectly good solution and build one from scratch. For now I've decided to use WBXML since its about as good as you can get for our application. But if the W3C were to come up with a better or more accepted standard we would use that (if it solved the problem, of course. gzip doesn't). -MM
Received on Thursday, 20 February 2003 07:51:29 UTC