> It is (b).
>
> I wouldn't say it is "identical to referencing the parent parameter"
though. It isn't.
>
> Consider a parameter (P) that encloses a choice (C). Choice (C) may
be extensible. Parameter (P) may also have an extension point.
<allowedIn C> is not equivalent to <allowedIn P>.
>
Ah ok, so you do distinguish between those two cases in c and c++. Just
to make sure: Since the ROSpec parameter does not have a "Custom" field,
an <allowedIn>ROSpce is not valid in the c and C++ impl. To "place" an
extension in the SpecParameter choice (via its Custom Field), the user
needs to specify <allowedIn>SpecParameter.
Here are the corresponding definitions from llrpdef.xml
<parameterDefinition name="ROSpec" typeNum="177" required="true">
.....
<field type="u32" name="ROSpecID"/>
<field type="u8" name="Priority"/>
<field type="u8" name="CurrentState"
enumeration="ROSpecState"/>
<parameter repeat="1" type="ROBoundarySpec"/>
<choice repeat="1-N" type="SpecParameter"/>
<parameter repeat="0-1" type="ROReportSpec"/>
</parameterDefinition>
<choiceDefinition name="SpecParameter">
<parameter type="AISpec"/>
<parameter type="RFSurveySpec"/>
<parameter type="Custom"/>
</choiceDefinition>
Gordon Waidhofer wrote:
> It is (b).
>
> I wouldn't say it is "identical to referencing the parent parameter" though.
> It isn't.
>
> Consider a parameter (P) that encloses a choice (C). Choice (C) may be
> extensible. Parameter (P) may also have an extension point. <allowedIn C> is
> not equivalent to <allowedIn P>.
>
> In C and C++ there are type descriptors for choices. So it wasn't too hard to
> enforce <allowedIn>. In C# we ran into something and I can't remember exactly
> what, but IIRC we punted and allow any custom parameter at any extension
> point.
>
> -gww
>
> -----Original Message-----
> From: Christian Floerkemeier [mailto:[email protected]]
> Sent: Wednesday, August 12, 2009 5:05 PM
> To: LLRP Toolkit Development List
> Subject: Re: [ltk-d] LTK Java and Custom Parameters
>
>
> Gordon,
>
> we changed the LTKJava implementation to allow references to
> ChoiceDefinition to align it with the other implementations. However,
> from conversations with Rob it seems that we implemented the <allowedIn>
> referencing a ChoiceDefinitions different from what the C* (C, Cpp, C#)
> implementations have done. We assumed that the C* implementations
> implemented option a) below, but from Rob's comments it seemed that the
> C* implementations use approach b). Is that correct?
>
> <allowedIn> referring to instance of <choiceDefinition>
> a) extension parameter is allowed in any parameter that is listed by
> choiceDefinition if it has a custom field (in the case of SpecParameter,
> the extension is allowed in AISpec and in RFSurvey (both of which have
> Custom fields))
> b) extension parameter is allowed as parameter in ChoiceDefinition
> referenced if instance has a custom field. This is identical to
> referencing the parent parameter of the ChoiceDefinition instance in the
> <allowedIn>. In this particular case, this would be allowedIn ROSpec.
>
> Christian
>
>
>
> Gordon Waidhofer wrote:
>> 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
>
>
> ------------------------------------------------------------------------------
> 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
