> We’ve run into an issue with llrp-1x0-def.xsd and the use of LLRP vendor > extensions.
Paul, just to clarify: the issue you are raising is not about validating that the binary description of an extension (e.g. extensiondef.xml) validates against llrp-1x0-def.xsd but that the description of the LTK-XML binding of an extension does not validate against llrp-1x0.xsd. Is that correct? I was a bit confused because your email referenced llro-1x0-def.xsd. In case the above is correct: I think XML Schema does allow for importing complexTypes as long as they are named (e.g. LLRPStatus) and not defined locally/anonymously. I am not sure that there is need to define them as global elements. http://www.w3.org/TR/xmlschema-0/#import In LTKJava, the validator also seems to implement this behaviour and we can validate extension messages that have their own namespace and import from the current llrp.xsd. - Christian John R. Hogerhuis wrote: > 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
