Thanks John, I understand the side effects, but thought that the behavior you describe below is desirable rather than detrimental. For example, there are cases where a user would want to import a single LLRP parameter from LTK-XML into internal objects (e.g. .NET). It would not be possible to validate this parameter against the schema unless the parameters appear as root of the schema.
I'm OK with deferring this decision until a later time, but I'm curious what alternatives you were thinking about to address the issue of LLRP parameters within custom messages. Paul -----Original Message----- From: John R. Hogerhuis [mailto:[email protected]] Sent: Wednesday, June 03, 2009 10:50 AM To: LLRP Toolkit Development List Subject: Re: [ltk-d] Recommended change to llrp-1x0.xsd On Wed, Jun 3, 2009 at 10:22 AM, Paul Dietrich <[email protected]> wrote: > Developers, > > > > We've run into an issue with llrp-1x0-def.xsd and the use of LLRP vendor > extensions. If you build a vendor extension that contains a core LLRP > parameter, the message won't validate (against this schema) because the core > LLRP parameters are not a top level element of the schema). For example, we > use the LLRPStatusParameter within some of our custom messages as there was > no reason to re-invent a new error reporting scheme. Because LLRPStatus is > not in the top level of the llrp-1x0.xsd schema, these custom messages won't > validate even though they are compliant. > > > > The fix would be to add all the LLRP core parameters to the root elements in > the schema. E.g. where we have > > > > <!-- Message top-level elements --> > > <xs:element name="KEEPALIVE" type="llrp:KEEPALIVE"/> > > <xs:element name="CLOSE_CONNECTION" type="llrp:CLOSE_CONNECTION"/> > > <xs:element name="GET_READER_CONFIG" type="llrp:GET_READER_CONFIG"/> > > <xs:element name="DISABLE_ACCESSSPEC" type="llrp:DISABLE_ACCESSSPEC"/> > > <xs:element name="SET_READER_CONFIG" type="llrp:SET_READER_CONFIG"/> > > <xs:element name="ERROR_MESSAGE" type="llrp:ERROR_MESSAGE"/> > > . . . > > <xs:element name="LLRPStatus" type="llrp:LLRPStatus"/> > ... > Comments? Does anyone forsee any compatibility issues with this change? It is not clear to me yet that this is a good way to do this. The way the modeling works now (intentionally) is that only LLRP messages are allowed to be root elements in this schema. I think that is desirable since it is direct mapping of LLRP binary messages. Would not your solution permit parameters as the root element of documents? That would be an an unwanted side-effect of the proposed solution. That is, I don't think we want to consider a document of the form <llrp:LLRPStatus>...</llrp:LLRPStatus> to be valid, right? I strongly suspect there is a better way to do this that does not have this side effect. Like, the element types allowed at the extension point could be addressed head on. -- John. ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
