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

>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.

a) Who said "text" means "xml" ?
XML is an option, but in a 3-way fight 'binary' goes down early in the
fight, and the real question is if XML or non-xml-text format should be
the basis for the syntax.

Syntax.
That's all XML buys you 'for free'.
[Well, that plus a lotta tools, but also some drawbacks]

The magic XML wand doesn't inherently solve Vocabulary nor Semantics.
Just syntax.

Ditto for Text.

And points made by both Marshall + Margaret, IMO, also emphasize the
need for a good non-XML textual format.

Check out HTTP.
Now SOAP and XML-RPC.
Now go sniff a wire for DCOM, or IIOP, or NDR.
Hey, go play with some ASN.1.

Text vs. XML vs. Binary.

XML's nice in some ways, but less desirable than text for human reasons.
[And tools; there are many XML tools, but even more 'structured text
handling' options]

And both are far superior to Binary.

IMNSHO, of course :-)

	- Howard

-----Original Message-----
From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org]
On Behalf Of Marshall Rose
Sent: Thursday, July 21, 2005 10:48 PM
To: Margaret Wasserman
Cc: rfid@ietf.org
Subject: 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

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