On Dec 18, 2007 11:24 AM, Christian Floerkemeier <[EMAIL PROTECTED]> wrote: > > I am not in favour of shortening the strings. > > I just hope that there won't be any protocol identifiers with whitespaces in > the future like "ISO 18000-6B". Clients would have to parse the text field > and distinguish whitespace as list item delimiters from whitespaces in the > protocol identifiers themselves. >
Where that occurs, we map the whitespace to underscores or camel case. One of the purposes of the enum strings is to provide strings to use as constant identifiers in programs. So we have to be able to transform the enum strings to valid identifiers in LTK supported languages. The ideal is some predictable way of mapping the identifiers from the spec to enumeration strings. This is what we have attempted to do: if you see an identifier in the LLRP spec, you should be able to mentally transform it to an enumeration string, or at least identify it if it pops up in a programmer's editor. That said, other practical considerations than language compatibility may intrude, such as length of identifiers. > In Table 3, the LLRP spec says values 2-255 are reserved for future use. The > interpretation in llrpdef.xml and LLRP.xsd is that values other than 0 and 1 > are not allowed. I wonder whether this is too restrictive. Does future use > imply that this will be possibly handled in LLRP version 1.x? or via a > separate document in which these values are assigned? > That's my thinking. One would imagine a mapping of LTK-XML namespaces and LTK api versions to LLRP specification versions (plus extension sets). So to relax the restriction, the user would need to upgrade to a new version of the xsd, xml file, and regenerate LTK code to match if using a code generation approach. This permits proper enforcement of RFU fields, which is a good thing. As it turns out, LTK-Perl routines have a "Force" flag to ignore such restrictions and make a best effort to format the message exactly as your request. This is there for testing purposes. -- John. ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
