>> Jean-Sebastien Delfino wrote:
Reading the composite file / building its model / re-writing it to
finally apply the xpath sounds very complicated.
As an application developer I'll write the appliesTo xpath to match what
I see in a composite XML file. Why can't we simply run the xpath on that
original XML file before doing all the other steps?
Venkata Krishnan wrote:
We will not be writing the entire composite, but only a fragment that is the
parent of the intentAttachPoint. Here is what the spec says : -
283 ..................................................Note that the XPath
expression will always be evaluated
284 within the context of an attachment considering elements where binding
instances or
285 implementations are allowed to be present. The expression is evaluated
against the parent element
286 of any binding or implementation element.
..........................................................
But then, it seems like we may have to look beyond the immediate parent or
maybe the entire composite if your proposal is to be taken.
Yes, but it's not incompatible. Here are some examples:
appliesTo="binding.ws"
appliesTo="[EMAIL PROTECTED]'AccountService']"
appliesTo="../[EMAIL PROTECTED]'AccountServiceComponent']"
appliesTo="/[EMAIL PROTECTED]'bigbank']/[EMAIL
PROTECTED]'AccountServiceComponent']"
By default you are in the parent of a binding or implementation, but can
use .. or / to go up.
I'd like to hear some perspectives from the specs folks on this.
>
Now, getting to your question more specifically on why this must be done
post-build phase, here it is....
- Firstly we need the PolicySet definitions to get hold of the
'appliesTo'.
- For PolicySets that are specified in the composite, they are resolved
during the resolution phase.
- For those that have to be calculated based on the Intents specified,
there needs to be a complete assembly model that is wired, since we also
need to take into account the target's intents. This wiring is being done
on the 'wireComposite' method of the CompositeWireBuilder.
- So the calculation of PolicySets is pushed to this point i.e. its being
done as part of the 'wireComposite' method, the moment the model has all its
connections resolved.
- Only after the PolicySets are calculated, do we have a handle on the
'appliesTo' attribute of the PolicySets.
How about this:
load the definitions.xml files declaring policySets.
for each policyset
prepend /*/*/ to its appliesTo xpath
for each composite XML file
run the xpath expression against the file
for each matching element
add the policySet to an imaginary "applicablePolicySets" attribute
end
end
end
Then later when you run the composite processors, builders etc, use the
intents + policySets + applicablePolicySets attributes to figure the
effective policySets.
This should provide the best of both worlds:
- xpath expressions evaluated against the real authored XML artifacts
- support for the intent/policySet matching algorithm from the spec
Makes sense?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
