On 8/20/07, Prasith Govin <[EMAIL PROTECTED]> wrote: > 3) XSD/XML Discussion (warning near-religious topics ahead) > - One of the more interesting topics and something that the group > dived into depth on was the necessity for both the LLRP.xsd (abstract > LLRP description) and LLRPDef.xml (LLRP Binary encoding) in the LLRP > common package. Even though we understood what the intent of each of > them are we left wondering due to some of the redundancy in what they > describe and somewhat similar roles if they are both absolutely > necessary. Even though we had differing sides on which was more useful > (XSD or XML) we both agreed on the general duplication of certain > elements and information that is common between both. > * This is an Item that Christian and his group will research > further and provide a detailed analysis on and would like to defer the > discussion of this for that email thread.
Color me confused... the necessity for both is absolute. Let me sidestep whatever religious issue might be here that I do not understand and talk about the practical utility of LLRP.xsd vs. llrpdef.xml. Of course there is duplication between LLRP.xsd and llrpdef.xml. LLRP.xsd can in fact be autogenerated from llrpdef.xml. llrpdef.xml is, information-wise, a superset. However, your friendly neighborhood XML text editor doesn't understand llrpdef.xml as a schema format. So, you cannot validate XML documents or get intellisense while creating LLRP xml documents without LLRP.xsd. LLRP.xsd is there to assist in creating instances of LLRP-XML and in validating those instances. llrpdef.xml is a definition of the binary protocol used to inform interpreters or generate code that can serialize and deserialize LLRP binary messages. Assuming all applications were schema-aware could this be factored out a bit better? Certainly. It would use LLRP.xsd for most everything, and llrpdef.xml would become a repository for whatever was left over: Type IDs, version ID, bit packing, etc. Would that be a good choice for Common? No, because it forces all code generation and certainly all interpreter strategies to become schema-aware. I don't see that as realistic. Note that LLRP.xsd is *not sufficient* to allow you to convert from LLRP-XML to LLRP binary. The Type-IDs, enumeration IDs, bit packing information, at the very least, are not there. LTK-Perl, LTK-C, LTK-CPP all use llrpdef.xml for generating data structures and/or code. None of them are schema-aware. If the Java app wants to be schema-aware, I think that would be beautiful, and I am frankly interested to see how it's done. But llrpdef.xml is not going to change or go away. So for the additional information you need, like Type IDs, enumeration values, bit packing etc. you would do well to plan to walk llrpdef.xml for that information. You would have to ask "what would that buy me." Does it buy you easier encoding/decoding to XML? Does it allow you to properly deal with Names vs. Types (TagPattern1/TagPattern2 vs. C1G2TargetTag). If so then I can see how that would be very valuable. At some point in designing LTK-Perl, LTK-C and LTK-CPP we chose the path of llrpdef.xml being the central repository of information necessary both to generate the LLRP.xsd and parser/builders of the binary format. It is not hard to walk with virtually any XML toolchain. W3C XML Schema is a whole different story. We use LLRP.xsd for the most part just to inform our XML editors about LLRP so we can easily create instances of LLRP-XML. HTH -- 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
