In custom definitions, we restrict/extend core messages and parameter extension points using the 'allowedIn.' I'm not a big fan of this... it implies that we're saying something about the custom type being defined when in fact we are extending a completely different type.
I think it is like this because there is no other obvious place to put it if you leave the llrpdef.xml inviolate when adding vendor extensions. I think it would be easier to understand if the extension productions were separated. <customParameterDefinition name="AcmeExtA" vendor="Acme" subtype="50"> <field type="u16" name="ExtAField" enumeration="AcmeExtAEnum"/> <parameter repeat="0-N" type="Custom"/> <allowedIn name="GET_READER_CONFIG_RESPONSE" type="GET_READER_CONFIG_RESPONSE" repeat="0-1"/> <allowedIn name="SET_READER_CONFIG" type="SET_READER_CONFIG" repeat="0-1"/> </customParameterDefinition> becomes something like: <customParameterDefinition name="AcmeExtA" vendor="Acme" subtype="50"> <field type="u16" name="ExtAField" enumeration="AcmeExtAEnum"/> <extension-point/> </customParameterDefinition> <extendMessage type="GET_READER_CONFIG_RESPONSE"> <allow type="AcmeExtA" repeat="0-1"/> </extendMessage> <extendMessage type="SET_READER_CONFIG"> <allow type="AcmeExtA" repeat="0-1"/> </extendMessage> <extendParameter type="AcmeExtA" namespace="Acme"> <allow type="UnivFutureBlah" repeat="1-1"/> </extendParameter> Seems much cleaner to me. It is more like the xml schema approach, and clearly they put a lot of thought into extensions. We might be avoiding some problems that way. For example, with this approach you could conceivably "allow" an extension in an additional type without modifying the main Acme extension file. With the existing approach, the "include" level extensibility dead-ends at an extension file. If you want to extend an extension, you have to modify the existing extension file. So we have a bit of asymmetry here if we leave it as-is. Plus it is a basic object oriented principle of coupling. allowedIn more tightly couples a customParameter or customMessage definition to core types. The custom types should be able to stand-alone until the designer decides to make an association. Any obvious problems with such a change? What is the impact to existing code we can do anything about (in LTK repository or another public repository) -- 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
