- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Tue, 03 Dec 2002 12:07:49 +0100
- To: Dan Connolly <connolly@w3.org>
- CC: www-tag@w3.org
Dan Connolly wrote: > Here's a conversation I see repeated about > every 6 months: Indeed. > A: XML is too verbose for low-bandwidth environments > B: so compress it > A: but we don't want to spend the battery/cpu/RAM > to uncompress it; we just want a binary > datastructure of the parse tree > B: oh bother. Go ahead, but don't ask > the XML community to endorse it. > > and it often stops there, at a stalemate. Which unfortunately doesn't do much to promote interoperability. One of the current issues with binary XML is that people are doing it. But because there's little information on the topic out there, it would seem that every standards organisation, consortium, etc seems to be wanting to come up with their own ad hoc format. I'm not saying that there should be a single binary encoding for XML, but surely avoiding complete balkanisation is a worthy goal. > B: well, what you do in the privacy of > your own home/trusted-net is your business. > If this isn't about interoperability > between arbitrary parties in the net/web, > then you really don't need our endorsement, > do you? It's rarely about interoperability between radically arbitrary parties on the Web, and often about home/trusted networks. However there is some area in the middle that is at the same time arbitrary (you don't know the other side, and new participants can join in at any moment) and not (all participants are using agreed-upon technology). In my experience, that area also represents a large part of the requests for binary XML. They are often industry groups of various sizes and importance (TV Anytime, MPEG-7, 3GPP...). PS: In case there's a doubt: I don't get any compensation from Expway to discuss binary XML in public, I'm just your average Perl hacker that likes the tech he's working on, and thinks it's useful :) -- Robin Berjon <robin.berjon@expway.fr> Research Engineer, Expway 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Received on Tuesday, 3 December 2002 06:08:28 UTC