Re: [Rfid] XML vs. Text vs. Binary
Margaret Wasserman <margaret@thingmagic.com> Sat, 23 July 2005 13:19 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwJuG-0006T5-Uj; Sat, 23 Jul 2005 09:19:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwJuF-0006T0-C3 for rfid@megatron.ietf.org; Sat, 23 Jul 2005 09:19:07 -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 JAA24420 for <rfid@ietf.org>; Sat, 23 Jul 2005 09:19:05 -0400 (EDT)
Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwKOh-0004qv-EJ for rfid@ietf.org; Sat, 23 Jul 2005 09:50:35 -0400
Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 449698; Sat, 23 Jul 2005 09:12:53 -0400
Mime-Version: 1.0
Message-Id: <p062007e5bf07e08eede4@[192.168.1.105]>
In-Reply-To: <DD9FF084-9F10-4098-B930-5893CDB93935@dbc.mtview.ca.us>
References: <0E03681B885F3B4296B999E34435A16E01234C2B@ms08.mse3.exchange.ms> <p062007c3bf05ec0041ed@[192.168.1.105]> <B327225C-65DB-44B2-859C-F645C2A36AA1@dbc.mtview.ca.us> <p062007ccbf06aca8d9aa@[192.168.1.105]> <DD9FF084-9F10-4098-B930-5893CDB93935@dbc.mtview.ca.us>
Date: Sat, 23 Jul 2005 09:14:45 -0400
To: Marshall Rose <mrose+internet.ietf.rfid@dbc.mtview.ca.us>
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: Re: [Rfid] XML vs. Text vs. Binary
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: rfid@ietf.org
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
Hi Marshall, I think we are mostly in agreement about the technical trade-offs, but for some reason that doesn't lead us to the same conclusion... At 9:16 AM +0530 7/23/05, Marshall Rose wrote: >this brings us back full circle: as soon as you have any level of >nesting, human type-in becomes problematic. as soon as you decide >that human type-in isn't mandatory, it is trivial to include a >standard library to do the heavy lifting while the humans invoke the >tool using textual commands. Yes, if there is any significant nesting, I agree that a human will not be able to type the commands in from memory and/or by glancing at a reference sheet. However, I don't see any reason why this protocol would require significant nesting, at least for the types of commands that a human is likely to use directly. With a text encoding, a human could also have certain prepared commands and be able to cut and paste them into the interface -- a command to reset autonomous operation, for example, or to set a reader to its default state. Or they could write simple scripts that would send specific commands or command sequences. >in other words, from where i sit, XML, cXML, etc., enjoy all the >drawbacks of both purist approaches. Correct, from a "human typing" standpoint, XML, cXML and a specialized text encoding are all roughly equivalent. However, in my opinion, they are all much better than a binary encoding. There are two factors involved here, and all three of these choices (XML, binary or specialized encodings) are fundamentally different WRT these factors: (1) Can the incoming stream be parsed by a widely available parser, or is a specialized parser necessary. XML parsers are available for all likely client systems, but a specialized text encoding or a binary encoding would require a specialized parser. BTW, subsetting XML _does not_ require a specialized parser. Reader vendors might want to includes a specialized (smaller or faster) parser and simply reject XML constructs that are not included in the subset, but clients could use a regular XML parser for this purpose. (2) Can text processing tools be used to send control messages and interpret the responses, or would binary processing be required. Both XML and a specialized text encoding would allow text processing of the messages and results, while a binary encoding would require binary processing. You've indicated that it is possible, with a binary encoding, for clients to run a tool that gives them text-based access. That's true, but users would need to _get_ that tool from somewhere... So, we are back to requiring specialized code on the client side to access this protocol. This isn't a religious issue with me -- I've just learned the benefits of text-based encoding the hard way, and I don't want to deal with another binary protocol... So, for the moment, we may have to just agree to disagree. We'd obviously need to resolve this before we can move ahead, though. Only a few of us have expressed any opinion on this subject. Are there others out there that have an opinion? There are two questions that I'd especially like to hear answered by specific other people on this list: (1) I'd like to hear from other reader vendors about whether they think that XML would place a prohibitive burden on their readers. It has been asserted that XML would have prohibitive system requirements for the reader. That certainly isn't true of ThingMagic's networked readers. In fact, using a standard parser, like XML, would reduce our development (especially debugging) and testing costs substantially, and would make it more likely that we would implement this protocol. (2) It would be very interesting to know if RFID users would see any benefit to a text-based encoding. Are there folks on this list who have RFID installed in real-world or even pilot installations (not just a few units in a test lab)? Do you have any opinions about whether the ability to access the reader using text-based tools from a client system that doesn't have a specialized client (or library) installed would be useful? Or do you see this as having little/no value? Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid
- [Rfid] XML vs. Text vs. Binary Margaret Wasserman
- RE: [Rfid] XML vs. Text vs. Binary Frederico, Gustavo
- RE: [Rfid] XML vs. Text vs. Binary Rob.Buck
- RE: [Rfid] XML vs. Text vs. Binary David Husak
- RE: [Rfid] XML vs. Text vs. Binary Margaret Wasserman
- Re: [Rfid] XML vs. Text vs. Binary Marshall Rose
- [Rfid] Re: XML vs. Text vs. Binary Stephane Bortzmeyer
- RE: [Rfid] Re: XML vs. Text vs. Binary Scott Barvick
- Re: [Rfid] Re: XML vs. Text vs. Binary Juergen Schoenwaelder
- [Rfid] Re: XML vs. Text vs. Binary Stephane Bortzmeyer
- [Rfid] Re: XML vs. Text vs. Binary Scott Barvick
- Re: [Rfid] Re: XML vs. Text vs. Binary Scott Barvick
- RE: [Rfid] Re: XML vs. Text vs. Binary Howard Kapustein
- Contradictions (Was: [Rfid] Re: XML vs. Text vs. … Margaret Wasserman
- RE: [Rfid] XML vs. Text vs. Binary Howard Kapustein
- RE: [Rfid] Re: XML vs. Text vs. Binary Howard Kapustein
- Re: [Rfid] XML vs. Text vs. Binary Margaret Wasserman
- RE: [Rfid] XML vs. Text vs. Binary Howard Kapustein
- Re: [Rfid] XML vs. Text vs. Binary Marshall Rose
- Re: [Rfid] XML vs. Text vs. Binary Margaret Wasserman
- RE: [Rfid] XML vs. Text vs. Binary Rob.Buck
- RE: [Rfid] XML vs. Text vs. Binary Bud Biswas
- Re: [Rfid] XML vs. Text vs. Binary Arjun Roychowdhury
- RE: [Rfid] XML vs. Text vs. Binary Scott Barvick
- RE: [Rfid] XML vs. Text vs. Binary Howard Kapustein
- RE: [Rfid] XML vs. Text vs. Binary Scott Barvick
- RE: [Rfid] XML vs. Text vs. Binary Howard Kapustein
- RE: [Rfid] XML vs. Text vs. Binary Rob.Buck
- RE: [Rfid] XML vs. Text vs. Binary Suresh Bhaskaran