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

[[e-mail]]

Viewpoint from another hardware vendor: 

If SLRRP gains traction we'll probably want to adapt it to a reader module
with a serial interface to maintain a common interface between readers.
However, if SLRRP is XML-based I don't think it will be viable for serial
I/O.  A minimal text protocol is marginal over serial.  Adding XML (even if
minimal) pushes the bandwidth over the top.

I agree with the human readable arguments of text vs binary.  With text
we've experienced lower training and support costs, faster time-to-market,
etc.  However, I foresee RFID development becoming more specialized with the
proliferation of readers in the supply chain.  It's likely that vertical
application developers will only concern themselves with a high-level
ALE-like interface.  RFID middleware developers will grapple with the
low-level interfaces.  We have a group of network programmers that tell me
they prefer a binary interface.  They have tools (LAN analyzers, etc.) to
work with binary so they're not concerned with human readable.  They argue
that programming to a binary interface is easier/higher performance than
parsing text.

Rob Buck
RFID Software Architect
Intermec Technologies, Corp.
Ofc: 641-472-3082
Cell: 319-573-5294
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Margaret Wasserman
Sent: Saturday, July 23, 2005 8:15 AM
To: Marshall Rose
Cc: [e-mail]
Subject: Re: [Rfid] XML vs. Text vs. Binary


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
[e-mail]
https://www1.ietf.org/mailman/listinfo/rfid
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  

_______________________________________________
Rfid mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rfid