On 9/20/07, Gordon Waidhofer <[EMAIL PROTECTED]> wrote: > > I am partial to allowedIn because I believe > it makes code generation easier. I am studying > the alternative extendParameter directive. >
On the face of it, it is not obvious to me why that would be. XSLT is based on XPath, which means it is possible to subset nodes of an XML file in fairly powerful ways. I am interested to hear what the problem is. > When an extension is defined -- most likely > by a reader maker -- it seems where the extension > is allowed would be entirely known. If the > extension originator will support the extension > in additional places, why wouldn't they modify > their description? What good does it do that > a third party could amend the description? > An amended description does not suddenly make > the reader able to support the extension in the > new place, right? John, do you have a practical > example of how those degrees of freedom would > be used? It is possible to put all of llrpdef.xml including extensions into one file. We don't do this, for various reasons. Instead we permit the conceptually cleaner solution of leaving the core file inviolate and adding extensions as separate files. Group A creates ExtA. On their reader they want it to show up in Message A, Message B, and Message C. Group B wants to adopt Group A's ExtA. They want to implement it in Message A, Message B, and Message C, but they also want it in Response D. With the new proposal they can leave Group A's definition inviolate. > > While I don't know the full impact of the > proposed change I am satisfied that it makes > code generation harder. Again, I'm interested to hear why. > I'd like to understand > how the greater effort is worth while. > I don't consider it a greater effort other than overcoming whatever inertia of existing approach. I think this way is cleaner, more analogous to the obvious object oriented architectures, more like XML Schema. So, permits easier extensibility, less risk (since it is more like existing approaches), keeps information where it belongs and out of where it does not belong... In fact, I think we'd all agree that for many reasons the right place for "allow" lines is at the extensionPoint definition in the parameter or message being extended. My approach is the closest I think we can get without hacking up the core files. -- John. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
