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

["Frederico, Gustavo" <[e-mail]>]

  XML is already the de facto standard for interaction between disparate
systems. That is clear to people that work in software and systems
integration. Perhaps it's not so obvious to folks that work mostly with
hardware. I would be concerned to used a protocol that is not XML-based
and defines software interface. The size of XML does not have to be so
much of a concern. It will probably be x % of what it would be if it
were not XML-based anyway. The human-readability of XML is not a problem
either, with a plethora of XML tools that facilitate editing and
generation. There are lots of packages for parsing in Java, Perl and
.NET compact framework. There's NanoXML, for instance, a light-weight
Java xml parser that requires 6K. There is work on W3C on a binary
representation of XML  ( http://www.w3.org/XML/Binary/ ), but it doesn't
seem to be finalized, and maybe it isn't necessary in this case either.
XML brings many benefits that are well-documented. What the group may
also consider is the use of RDF or OWL-Lite, for strong semantics and
scalability, that I think would fit configuration management very well.

Regards,
Gustavo Frederico
Allstream

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Margaret Wasserman
Sent: Wednesday, July 20, 2005 10:19 PM
To: [e-mail]
Subject: [Rfid] XML vs. Text vs. Binary


We've had some discussion on this list about XML encoding vs. binary 
encoding...

I'm not sure that we are in agreement on all of the related points, 
but the concerns with XML seem to be code size on the reader and 
protocol overhead on the wire.  These concerns can be minimized by 
the use of a restricted XML subset, such as canonical XML (see RFC 
3076).  However, there still seem to be some concerns along those 
lines.

The only advantages that I remember being discussed for a binary 
encoding were the complement to the concerns with XML:  smaller code 
size on the reader and less protocol overhead.

I think, though, that our discussions have missed a major benefit of 
any text-based encoding (whether a protocol-specific text encoding or 
canonical XML):  the ability to access the device using text 
processing tools (such as Perl scripts) and/or for a human to 
interact with the device directly.

In 2002, the IAB held a Network Management workshop that is 
documented in RFC 3535.  I would suggest that folks on this list read 
this report which can be found at:

http://www.ietf.org/rfc/rfc3535.txt?number=3535

One of the interesting findings of that workshop was that one of the 
significant barriers to the use of SNMP as a configuration or control 
protocol is that it uses a binary encoding, which means that 
SNMP-specific client software (an SNMP browser or manager) is needed 
to interact with the device via SNMP.  This prevents SNMP access 
using text processing tools or via human interaction.

I would not like to see the industry create the same problem with an 
RFID control protocol.

If there is real evidence that canonical XML would require too much 
code size on the reader and/or would result in an unacceptable level 
of protocol overhead, perhaps we could consider a protocol-specific 
text-based encoding (similar to FTP, SMTP and HTTP)?  I don't believe 
that parsing a well-defined text-based encoding would require much 
more code than processing a binary encoding.  And, in some cases a 
text based encoding would actually result in less data on the wire -- 
for instance a 32 bit integer with the value of 3 would be encoded in 
one byte of text ("3"), while it would require 4 bytes in binary 
encoding ("0x00000003').

Personally I like canonical XML, because I think it strikes a good 
balance between being human readable and machine-parsable.  I also 
like the fact that the syntax is already well-defined.  However, I 
think that well-defined, protocol-specific textual encodings could 
also achieve that balance, perhaps with less impact in the areas of 
concern (code size and protocol overhead).

What do others think?  Should we at least consider a text-based
encoding?

Margaret



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

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