> 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.
acmeExtensionDef.xml is mentioned in the LTK Structured Extensions document. I was refering to an acmeExtension.xsd (for the XML message binding). > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of John R. Hogerhuis > Sent: Mittwoch, 22. August 2007 16:48 > To: LLRP Toolkit Development List > Subject: Re: [ltk-d] XML file utility > > 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 > ------------------------------------------------------------------------- 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
