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

[Arjun Roychowdhury <[e-mail]>]

I am new to the RFID ietf group - however, I do believe it is normal
at the IETF to author requirement documents in situations like this
when there are clearly benefits of both XML and Binary. There have
been several discussions in various groups about XML vs. Binary and
unless there are clearly agreed upon requirements for the protocol in
question, I am pretty sure the discussions will never converge.

In the past, there have been other protocols that support both XML and
binary 'profiles' - however, that does add cost & complexity for the
vendor community.

There are two obvious disadvantages to XML - size and speed. However,
unless there is some concrete discussion on what really size and speed
means relative to the requirements of this interface, that discussion
cannot conclude, again.

I come from the applications space (VoIP, specifically) and my current
interest in RFID network side protocol lies in how to tie it with the
application layer protocol (for location based services) and therefore
naturally think XML suits better for this need.

However, I would love to see a specific requirement document that
gives this community a chance to discuss this issue in a more
structured manner.

regds
arjun

On 8/2/05, Bud Biswas <[e-mail]> wrote:
> I see the usefullness of both XML and binary to different vendors. Altho' it
> is true that programmers will generally prefer binary to work with, XML is
> also useful to a different user community (non programmers). My preference
> would be to see that Readers support binary as mandatory and XML as optional
> along with the Middleware supports binary as input from reader (mandatory)
> and XML input as optional. This will allow us to build both "thin" readers
> as well as "heavy duty" readers where the readers support XML also and may
> include the middleware software.
>  
> Bud Biswas
> 
> 
> [e-mail] wrote:
> 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 t! he 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
> 
> 
> 
> Polaris Networks
> your source for rfid test tools
> _______________________________________________
> Rfid mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rfid
> 
> 
> 


-- 
Arjun Roychowdhury

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