On Fri, Jun 5, 2009 at 5:59 AM, floerkem<[email protected]> wrote: > > Chris, > > As one of the "Java guys" :),
Hey, sorry for the pigeon-holing. But if the boot fits... > 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> > If we went down that road, LTK-Perl at least would need to be altered to accommodate, since it is fully namespace aware and would look up example:LLRPStatus and not find a rule for handling that. It is a backwards incompatible change. I'd rather stick with the LTK-XML format we've been using for extensions. That's where I think we should draw the line. Now, if W3C XML Schema can't validate this exact language, so be it. Maybe we can come up with a little custom XSLT to go the last mile of validation that W3C XML Schema is presumably incapable of. Or other validators like Schematron or RelaxNG might be able to do better, I don't know. I'm mildly hopeful there's a way to get W3C XML Schema to do what we want, but maybe we can't. If we can't I think we shouldn't change LTK-XML for a weakness in W3C XML Schema. That said, we need to continue to support W3C XML Schema as well as we can since it is widely deployed. Users may use it to validate instance XML and also with XML editors to create instance XML. I think the Paul/Chris schema is good enough for XML editing. Validation is a separable issue. It could be worse after all. At least the Paul/Chris schema recognizes a superset of LTK-XML. So W3C XML Schema is not entirely broken :-) -- 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
