The difference is one of lookup.
<allowedIn> means I only have to use ..
to find the relevant <customParameter>.
And .. can never fail. There is no sweating
error recovery.
<extendParameter> means that the code generator
XSLT has to take @name (or whatever) and search
from the root looking for the corresponding
<customParameter>. That alone is work. And it
can fail. What if @name isn't found?
It is not a complete argument. But it
demonstrates the extra effort.
I get the algebraic argument you gave on
the two groups applying extensions. It is
good but not convincing. Is a more concrete
example possible? Does anybody on the list
have one?
What I'm looking for is a scenario that
would *only* be possible to resolve using
<extendParameter> and could not be handled
by <allowedIn>.
Regards,
-gww
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of John R. Hogerhuis
Sent: Thu 9/20/2007 1:24 PM
To: LLRP Toolkit Development List
Cc:
Subject: Re: [ltk-d] Proposed change to llrpdef.xml [heur]
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
-------------------------------------------------------------------------
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
