On 7/19/07, Kyle Neumeier <[EMAIL PROTECTED]> wrote: > We also want to get other's input on this issue and see how other > projects are planning on handling this problem.
Well for the Perl stuff, I create the message in Eclipse XML editor based on the LLRP.xsd schema. This give intellisense as I go. In fact, if you just use the intellisense, you cannot construct a structurally invalid message (semantically invalid is another story... W3C XML Schema can't help much here). If you don't like Eclipse, you can use any good XML editor, or you can validate messages at the command line with something like xmlstarlet. I don't use ANY default values. I have thought about it from time to time, but I'm not sure I know enough to come up with a good set of defaults. Instead I took the approach of making it as easy and transparent as possible for the user to construct LLRP documents and embed them in code. If you want to see how it works take a look at my inventory example: http://llrp-toolkit.cvs.sourceforge.net/llrp-toolkit/Perl/examples/inventory_example.pl?view=markup Anyway in Builder.pm encode_message and decode_message I do some validation as I progress through the message. If I see an error I throw an exception. I have a 'Force' mode that will make it attempt to encode anyway so that I can test a reader's behavior given structurally invalid messages. For semantically invalid messages, I expect an error from the reader. Note that I am talking client-side here. For object-oriented APIs if you are clever enough to come up with good default values, I think you probably should come up with default values and subparameters. That said, if you go down that path I strongly recommend you be able to dump the resulting message as XML validating against LTK's LLRP.xsd . This way no matter what defaults you provide the user can print out "the real" LLRP message you are divining from what they actually told you to do. Using the LLRP.xsd message allows you to print the message in a 100% unambiguous way. Without a clear, textual serialization/deserialization format, I think supporting default values and subparameters would be a support nightmare. Another approach would be to create some high level factory objects with members that given a few parameters generate basic templates of some common LLRP animals. You can print in the documentation as LLRP.xsd what these things actually build given the input. This separates the "wizard" from the low level construction of messages where you may prefer not to make any guesses (you're probably at the wrong level of abstraction there to do so anyway). -- John. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
