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

> So, I will restate my opinion that we should not lightly develop an  
> RFID reader management protocol that can only be access from a  
> specialized client.

i guess we'd need to agree on the meaning of specialized before  
agreeing on this point.

> To your point about enumerated types, etc.... There is no reason  
> why a text interface couldn't allow well-defined strings to be used  
> for those enumerations (EPC0, EPC1, EPCG2, etc...), rather than  
> requiring the client (whether it is a piece of middleware, a Perl  
> script or a human typing at an SSH prompt) to send numerical values.

the problem, i think, is that the XML compromise, like most  
compromises, doesn't really solve anything; further, like most  
compromises, it works worse than most purist approaches.

it's certainly better than binary if you're going to type-in commands  
via telnet or ssh. the moment you have to start matching elements,  
and are typing more than a few of them, you need to have a tool do  
the typing.

as soon as you have tool do it, you've lost the text advantage  
because it's just as easy for a tool, perl-based or not, to spit out  
binary as xml.

my experience, which admittedly is dated, is that text works for  
debugging simple protocols like smtp. as soon as you introduce  
nesting, you lose the type-in advantage.

/mtr

ps: people who complain about the binary nature of snmp are actually  
complaining, whether they know it or not, about ASN.1/BER, which  
define how to describe and encode SNMP packets. i really should have  
listened more to chuck davin 20 years ago...

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