On Mon, Aug 10, 2009 at 1:51 PM, Christian Floerkemeier<[email protected]> wrote: > > thanks, Basil. I guess LTK is more complicated than just messages, > parameters and extension points :).
Yes my oversimplification (error). Message (core+vendor-defined), parameters (core+vendor-defined), fields, choices (I also call these "alternation points"), extension points, and custom parameters. What did I forget? > > I'd be interested though whether the other implementations allow > references to choiceDefinitions in the allowedIn construct and interpret > this as "allowed in any of the parameters belonging to this > ChoiceDefinition". At the end of the day, it is important that the > different implementations of the LTK are aligned. > IIRC, the allowedin in the case of a choiceDefinition simply adds the parent type being defined to what is allowed at the extension point of the referred type. For LTK-Perl, it is part of the logic of deciding "what is allowed here" as it does encode/decode from binary to/from XML representation. LTK-Perl doesn't have this problem of mapping the hierarchical structure onto a strongly typed object tree, since it performs no such mapping. In the LTK-Perl solution, I navigate the XML infoset using XPath. -- John. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
