What's your take on enumerations for Integer subtype fields? Strongly typed I guess? That would help with autocompletion as the identifiers are too long to type and get correct.
I didn't notice anything here about the abstract XML format. Do you intend to serialize/deserialize to the LLRP.xsd format? Do you use lists for all sets of subparameters are will you allow strongly typed references to individual subparameter objects? I see that you are attempting to make strongly, statically typed alternation (choice) points. Are you considering strongly, statically typed extension points (Custom) as well? Be aware in that regard that the two mix: there are some alternation points which are extensible. That may crystallize for you as LTK approach to extensions gets hammered out. Note that strong typing precludes modelling non-conforming messages. This is something that I permit in LTKPerl if you set a "Force" option when calling encode/decode. This permits negative testing, and is one reason I recommend the Perl stuff for testing purposes. Such a limitation on the Java toolkit is probably reasonable since its primary use will not be for testing. There are probably some hooks you could add to allow this if you thought LTKJava were going to be used broadly for testing. Maybe permit adding callback routines in the marshaller, which could override portions of the message at the binary level while the framework would recompute any Length fields as necessary. Later, -- 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
