RE: [Rfid] Re: XML vs. Text vs. Binary

"Howard Kapustein" <hkapustein@manh.com> Fri, 22 July 2005 14:37 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyeU-0005Qr-DI; Fri, 22 Jul 2005 10:37:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyeT-0005Qm-8a for rfid@megatron.ietf.org; Fri, 22 Jul 2005 10:37:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20701 for <rfid@ietf.org>; Fri, 22 Jul 2005 10:37:22 -0400 (EDT)
Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvz8h-0008C4-OB for rfid@ietf.org; Fri, 22 Jul 2005 11:08:41 -0400
Received: from ([10.100.101.63]) by relay3.manh.com with ESMTP id 4029073.7185807; Fri, 22 Jul 2005 10:36:08 -0400
Received: from ma-atl97.us.manh.com ([10.100.101.97]) by ma-atl63 with trend_isnt_name_B; Fri, 22 Jul 2005 10:06:05 -0400
Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl97.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 10:06:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Rfid] Re: XML vs. Text vs. Binary
Date: Fri, 22 Jul 2005 10:06:05 -0400
Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEBF7@ma-atl57.us.manh.com>
Thread-Topic: [Rfid] Re: XML vs. Text vs. Binary
Thread-Index: AcWOtrD9UpWdtpYBRTOscmq8grAXcgADSFiw
From: Howard Kapustein <hkapustein@manh.com>
To: rfid@ietf.org
X-OriginalArrivalTime: 22 Jul 2005 14:06:05.0564 (UTC) FILETIME=[803653C0:01C58EC6]
X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: quoted-printable
Cc:
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Control and Access of Infrastructure for RFID Operations Discussion List <rfid.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rfid>, <mailto:rfid-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rfid>
List-Post: <mailto:rfid@lists.ietf.org>
List-Help: <mailto:rfid-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rfid>, <mailto:rfid-request@lists.ietf.org?subject=subscribe>
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

>So designing for human readability in what is inherently
machine-to-machine
>operation does not seem like a requirement,

I'd agree, except there's one flaw in your statement:

	Humans *are* involved.

Unless you've found a way for machines to build the machines to talk to
machines, but I thought SkyNet wasn't operational yet.


I've worked with a variety of protocols and formats, and to be honest if
I have to deal with one more friggin' binary protocol I'm going to have
the urge (yet again) to kill something.

The efficiency tradeoff is largely a red herring.
*Pragmatically* speaking, it's a wash.
There are some minor perturbations each way, but they're not
significant. Not in this space.

I've seen various encodings.
I've done the math.
I've written code, both high and level level, to build and parse such
data streams.
I've even shipped products.
***It's a wash.***

A *well-designed* text format is equivalent to a *well-designed* binary
format, in terms of size, memory utilization, parse efficiency and so
forth, for these needs.



But...when it comes to *using* the format, TEXT IS ALWAYS SUPERIOR TO
BINARY.

Unless someone knows a way to take the 'human' factor out of it.

Text formats are far more amenable to lower effort to use, to
troubleshoot and to do so correctly. They lower the barrier to entry.
The encourage more exploration more easily.

Given the technical delta is effectively nil, and the *human* factor is
significantly tilted in favor of a textual/non-binary format, I fail to
see how a 'binary' format is compelling over 'text'.



On the efficiency side, I would love to see someone challenge my
assertion -- WITH NUMBERS.

No anecdotes.
No opinions.
Cold hard clear factual values.

	- Howard

P.S. When I say 'text' I mean non-binary, in the traditional senses of
the words. XML is textual, but often fails the bandwidth/size issue vs.
other (esp. more specialized) text formats, designed for more efficient
size + utilization. XML is great for data not because it's inherently
great, but because everyone (esp. every vendor) agreed "it's good
enough". The *everyone* part is why XML is successful. YAML, JSON and
other formats are superior in some technical ways, but given the breadth
acceptance ("even if we don't love it, we don't hate it") it's often a
good solution. In this case? That's up for debate.

But ignore XML; it's a subset of 'text'.

In the 'binary' vs. 'text' Steel Cage Deathmatch, both will be bloodied,
both will be weary, and **the audience** will come on stage and crown
'text' the champion.

_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid