On Nov 14, 2007 3:44 PM, Paul Dietrich <[EMAIL PROTECTED]> wrote: > One interesting side not, is that if EPCglobal ever chooses to use one > of these bits, the llrp.xsd schema will not be backward compatible (nor > will the abstract LLRP definition). However, one could argue that the > llrp binary protocol will still be backward compatible. E.g. a reserved > bit which must be zero in llrp 1.0 means "I support new feature X" in > llrp 1.1. >
True, I guess, depending on your definition of "incompatibility" but it will never be a problem in practice even at the abstract level as long as applications do not fill it in when *decoding* binary messages. If someone specifies the Reserved attribute they presumably know what they are doing. Reserved means reserved. The semantic of this field is that is an "override" to be used when specifying abstract xml document instances to be converted to binary. Binary decoder applications should not fill in this attribute as a matter of course. Perhaps that is the moral of this discussion. Do we need a clearer comment in the xsd file? -- John. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
