On 8/22/07, Christian Floerkemeier <[EMAIL PROTECTED]> wrote: > > > thanks for putting the document together, Paul. I think it is very useful. > > When we had the discussion among the Java developers the other day (which > summary Prasith posted to the list on Monday), we agreed on the need to have > a description of the binary encoding and (!) the need for a schema to > validate the LLRP XML instances. What concerned us, was really how the two > stay synchronized and whether it would be benefitial to generate one from > the other. > > I guess it should be straightforward to maintain a consistent representation > of llrpdef.xml and LLRP.xsd in the LTK project (even if do not generate > llrp.xsd from llrpdef.xml in the future) and we can safely assume that they > are consistent. We were not so sure about the vendor extensions though. What > happens if a vendor extension specified in acmeExtensionDef.xml (according > to llrpdef.xsd) is not consistent with acmeExtension.xsd (the schema to > validate the additions to the LLRP XML message format). Will we need to > check for consistency in the LTK implementations? This assumes by the way > that vendor extensions will have an "acmeDefinition.xsd" - I thought this > was the case, but I just checked the LTK Structured Extensions document and > it was not mentioned. >
I in fact have an XSLT that generates llrp.xsd from llrpdef.xml. Once extended with support for extensions, it will probably be contributed. It's not a problem yet since details on Structured Extensions is still in flux. llrp.xsd hopefully won't change except when the LLRP standard changes. There is still some leeway on how exactly to do dependecies between schemas for vendor extensions... import or include, dependencies between schemas or just generate whole new ones, etc. One of the critical factors here is ensuring compatibility with text editors since it is conceived that llrp.xsd and variants will be used to validate XML instances and help give autocompletion in XML-aware text editors. If the structure is too complex I fear that Eclipse will choke on it. Anyway, currently llrp.xsd just has an xsd:any with namespace=#other at the extension points. But definitely there will need to be "strongly typed" schemas that do not use xsd:any. So for Acme reader there would be Acme.xsd based on acmedef.xml. Note that it is also conceivable that a given reader or client would implement structured extensions from multiple vendors, so whatever script finally results has to be able to pull subsets of definitions from multiple definition files. I may adopt one of AcmeCorp's extensions, 5 from AcmeUniversity, a couple from LTK project itself if LTK ends up getting a vendor ID. An acmedef.xml is definitely necessary in any case. If it was not mentioned in the doc it I'm sure it was just an oversight. -- John. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
