Chris, As one of the "Java guys" :), I am not convinced that we should make this change.
* With this change, we can no longer verify that an LTK-XML message is in fact an LLRP compliant message using xsd validation (LLRP parameters by themselves will be validated as well). In my opinion this outweighs the benefits of being able to validate individual parameters in LTK-XML format. It also means that we would need to modify the existing implementations to maintain the same behavior. We would need to check the root element in any LTK-XML message against a list of valid LLRP Messages. * I agree that to the user it is not obvious from looking at the XML entity itself that LLRPStatus is an instance of the llrp namespace complexType LLRPStatus (see example below). However, nested elements of LLRPStatus will be qualified by the llrp namespace which will reduce potential confusion. The developer using the LTK-XML extension message will also be able to check in the extension schema. <example:LLRP_CUSTOM_MESSAGE MessageID="1001" xmlns:example="http://ltk.example.com/ltk/schema/encoding/xml/0.1"; xmlns:llrp="http://www.llrp.org/ltk/schema/core/encoding/xml/1.0";> <example:LLRPStatus> <llrp:StatusCode>M_Success</llrp:StatusCode> <llrp:ErrorDescription></llrp:ErrorDescription> </example:LLRPStatus> </example:LLRP_CUSTOM_MESSAGE> * In the proposed schema, the note says: "It allows typical schema-aware XML editors to validate LTK-XML documents that include vendor extensions utilizing parameters within the core LTK-XML namespace." Are you saying that most typical schema-aware XML editors would not validate extension messages that import complex types as above and as in the current xsd? I thought the problems with the validation with XMLStartlet and the other tools you tried arose from using the ref attribute with a complexType rather than an element (which is not foreseen in XSD)? Christian Chris Delaney wrote: > John, > > I am not sure how the LTKJava team utilizes llrp.xsd, though I assume they > will comment on the proposed change once they have time to review. To > facilitate the review process, I have attached an updated llrp.xsd. The > comment block may not be as fat and descriptive as you'd like, so please feel > free to expand. > > Hopefully we can get a go/no-go consensus for the change from the Java folks > over the next day or so. > > Thanks again, > > C > > -----Original Message----- > From: John R. Hogerhuis [mailto:[email protected]] > Sent: Thursday, June 04, 2009 3:30 PM > To: LLRP Toolkit Development List > Subject: Re: [ltk-d] Recommended change to llrp-1x0.xsd > > On Thu, Jun 4, 2009 at 3:22 PM, Chris Delaney <[email protected]> > wrote: >> John, >> >> I've got a pretty hard stop early next week. At that point whatever state >> the schemas are in is pretty much how they'll stay. That said, if there is >> an elegant solution available via W3C, I'm all for finding it. I completely >> agree that the current distinction between core and extension parameters is >> pleasing and should be preserved if possible. >> >> Do you know of an appropriate forum to pose this question? I feel like I'm >> at most informed, so if you have any contacts or thoughts, please pull them >> in to the discussion! I agree that there should be a way to do this, so >> hopefully we're just missing something... But absent an elegant method, a >> big fat comment in the XSD would also work for me. >> >> Thanks, >> >> C >> > > Well that's probably not enough time to work though this. > > So I say just put in your change for now unless the Java guys object. > It doesn't really hurt anything and we can clean it up later. > > I have a vague memory that the Java guys actually process the XSD so > this could be bad for them. > > Is that true? > > -- 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 ------------------------------------------------------------------------------ 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
