LTKC, LTKCPP (C++), and LTKNet all support <allowedIn> referring to <choiceDefinition>s. It is quite necessary.
-gww -----Original Message----- From: Christian Floerkemeier [mailto:[email protected]] Sent: Monday, August 10, 2009 1:51 PM To: LLRP Toolkit Development List Subject: Re: [ltk-d] LTK Java and Custom Parameters thanks, Basil. I guess LTK is more complicated than just messages, parameters and extension points :). I'd vote for not allowing references to choiceDefinitions in allowedIn statements. llrpdef.xsd says that the allowedIn element references entities of the allowedInParameterReference type (and not allowedInChoiceAndParameterReference). While references to parameter definitions only are of course not enforced by llrpdef.xsd, the naming suggests the use of parameter and not choice definitions. For LTKJava, allowing reference to choiceDefinitions would also mean additional work. 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. Christian Basil Gasser wrote: > I think we have the problem of looking at things from two different > directions. We either look it from an XML perspective, that's what you > suggest, John, and that's were probably something defined through an > allowedIn element should only appear in whatever it was defined to be > allowed in. > > However, if we start to think slightly object oriented we start to mix > things. SpecParameter is a choiceDefinition. That's how I came up with the > term interface - if you interpret things in a object oriented way, a > choiceDefinition defines an interface (or an abstract class) implemented by > whatever is defined in the choice definition (AISpec, RFSurveySpec, Custom > in the case of SpecParameter). Further, if you define something to be > allowed in a SpecParameter you also intend it to be allowed in a > AISpec/RFSurveySpec/Custom since every instance of such a parameter is an > instance of a SpecParameter. In that case, Rob's assumption that by defining > something to be allowedIn a SpecParameter it would actually also be allowed > in any parameter defined in the choiceDefinition is perfectly reasonable. > > I guess the question really is if we want to have this Java-like perspective > or if we want to stick to the pure XML perspective without interpreting > things. > > Am 8/10/09 9:22 PM schrieb "John R. Hogerhuis" unter <[email protected]>: > >> On Mon, Aug 10, 2009 at 11:53 AM, Basil Gasser<[email protected]> wrote: >>> Hi Rob, >>> >>> That¹s acutally a really interesting case you created, not sure if we have a >>> bug here. I think you define your parameters correctly using allowedIn, >>> however, some of your parameters are defined as allowedIn for an interface >>> type. For example you have <allowedIn repeat="0-1" type="SpecParameter"/> >>> Now, SpecParameter is an interface implemented by AISpec, RFSurveySpec and >>> Custom (where Custom is again implemented by some of your types). I assume >>> that defining as allowed in SpecParameter what you actually wanted is having >>> it allowed in all implementing classes. >> I'm getting confused by the jumping between levels. Classes, >> interfaces? We should be able to consider this at the LTK-XML level, >> only, I think. >> >> At LTK-XML level, our universe is Messages, Parameters, and Extension >> Points. A Parameter is either allowed at an Extension Point, or it is >> not. >> >> So if the def says <allowedIn repeat="0-1" type="SpecParameter"/> that >> means that the SpecParameter Parameter can have a *whatever the >> containing definition of the allowedIn clause* at SpecParameter's >> extension point, everwhere SpecParameter SpecParameter appears. >> <allowedIn/> is a funny contruct from an architectural point of view, >> but that's how it works. >> >> So, I think that's what you're getting at Basil. If so, yeah that >> allowedIn clause wouldn't say anything about the extension point of >> any other parameter than SpecParameter. >> >> -- 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 > > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 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
