[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-policy] Further Thoughts on Issue 87
So we should open the issue and clarify the wording. I'm also in favor
of adding Raymond's example but
a bit worried that a large example will break up the flow of the
document. Perhaps as an Appendix?
All the best, Ashok
David Booz wrote:
>
> Include processing is slightly different from the include-like process
> that happens to deployment composites. For example, composite services
> and references are treated differently. Raymond and I looked at the
> text in assembly which talks about deployment as an include operation.
> I came to the conclusion that a wording tweak is needed there. Aside
> from the examples Raymond cited, it would also be useful to clarify
> the words in policy to say that @attachTo xpath expression evaluation
> happens AFTER deployment. I think it's too subtle to expect the reader
> to pick up on the "include" words as also referring to deployment.
>
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
>
> Inactive hide details for Mike Edwards ---09/22/2009 05:33:53
> AM---Raymond, OK, thanks for the reply - and I think that you mayMike
> Edwards ---09/22/2009 05:33:53 AM---Raymond, OK, thanks for the reply
> - and I think that you may have some useful
>
>
> From:
> Mike Edwards <mike_edwards@uk.ibm.com>
>
> To:
> "OASIS Policy" <sca-policy@lists.oasis-open.org>
>
> Date:
> 09/22/2009 05:33 AM
>
> Subject:
> Re: [sca-policy] Further Thoughts on Issue 87
>
> ------------------------------------------------------------------------
>
>
>
>
> Raymond,
>
> OK, thanks for the reply - and I think that you may have some useful
> examples that we can add to the spec.
>
> Comments inline.
>
> Yours, Mike.
>
> Strategist - Emerging Technologies, SCA & SDO.
> Co Chair OASIS SCA Assembly TC.
> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
> Email: mike_edwards@uk.ibm.com
>
> From: Raymond Feng <rfeng@us.ibm.com>
> To: "OASIS Policy" <sca-policy@lists.oasis-open.org>
> Date: 21/09/2009 23:29
> Subject: Re: [sca-policy] Further Thoughts on Issue 87
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi, Mike,
>
> Thanks for the clarification. I put together a sample scenario at [1].
> In this case, two composites Composite 1 and Composite 2 are deployed
> to the SCA domain. Composite 1 includes Composite 3 while Composite 4
> is used as implementation.composite for both Component1B and
> Component2B. I have a few questions with some possible interpretations.
>
> What are the composites in the info set to apply the xpath?
>
> * domain composite, composite 1, composite 2 and two copies of
> composite 4?
> * domain composite and two copies of composite 4? *
> <mje> It's this second case. Composite1 and Composite2 don't really
> exist in the configuration - what is there is the set of* *
> components that they contributed into the Domain composite -
> Component1A, Component1B, Component2A, Component2B.* *
> </mje>*
> * or?
>
> Does the xpath apply to Composite 1 and 2 before they are added to the
> Domain Composite?
> Or do we only evaluate the xpath against the Domain Composite after
> the virtual includes are processed? *
> <mje>* *
> I thought that the Policy spec was explicit on this point, so your
> question has me worried that adding stuff to the Domain composite is* *
> not well described enough (and this is an issue for the Assembly spec). *
> *
> Include processing is done FIRST - before any XPath evaluation. This
> covers the include processing implied by the deployment of* *
> composites into the Domain.* *
> </mje>*
>
> Can we give a few examples here? *<mje> Sure - and perhaps we can add
> these to the spec to aid clarity</mje>*
>
> a) Select all top-level components in the domain:
> //composite[@name='']/component * <mje> Yep </mje>*
> b) Select all components in Composite1 (Is it even possible to use the
> attributes of the <composite>?):
> //composite[@name='Composite1']/component *
> <mje>There is no obvious way to do this.</mje>*
> c) Select Component3A: //component[@name='Component3A'] * <mje> Note
> that this selects all components with a name Component3A </mje>*
> d) Select Component4A on path Component2B/Component4A:
> //component[URIRef('Component2B/Component4A') *
> <mje> Yes, this selects a specific use of Component4A - guaranteed
> unique </mje>*
>
> Thanks,
> Raymond
> [1]
> _http://svn.apache.org/repos/asf/tuscany/java/sca/modules/policy-builder/src/test/resources/org/apache/tuscany/sca/policy/builder/impl/scenario.png_
> ------------------------------------------------------------------------
> *Raymond Feng*
> Senior Software Engineer, Apache Tuscany PMC Member & Committer /
> IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster City, CA
> 94404, USA/*/
> E-mail/*/: //_rfeng@us.ibm.com_/ <mailto:rfeng@us.ibm.com>/,
> /*/Notes/*/: Raymond Feng/Burlingame/IBM, /*/Tel/*/: 650-645-8117,
> /*/T/L/*/: 367-8117/*/
> Apache Tuscany/*/: //_http://tuscany.apache.org_/
> <http://tuscany.apache.org/>/
> Co-author of Tuscany In Action: //_http://www.manning.com/laws_// /
> ------------------------------------------------------------------------
>
>
> Mike Edwards <mike_edwards@uk.ibm.com> wrote on 09/21/2009 04:59:25 AM:
>
> > From:
> >
> > Mike Edwards <mike_edwards@uk.ibm.com>
> >
> > To:
> >
> > "OASIS Policy" <sca-policy@lists.oasis-open.org>
> >
> > Date:
> >
> > 09/21/2009 05:00 AM
> >
> > Subject:
> >
> > Re: [sca-policy] Further Thoughts on Issue 87
> >
> >
> > Folks,
> >
> > There is a basic misunderstanding that is affecting this debate.
> >
> > It follows from a statement made early on:
> >
> > "My understanding is that we use the domain composite as the infoset
> > to apply the
> > xpath for @attachTo. All included composites have been merged before
> > the evaluation."
> >
> > NO. This is NOT what is meant by the "Infoset for External Attachment"
> >
> > What it means is ALL SCA Composite files. Not some tree starting at
> > the Domain Composite, but the set of separate
> > files.
> >
> > So there is NEVER any question of having to recurse into some
> > <implementation.composite/> element.
> >
> >
> > This was the whole point of defining the Infoset for External
> > Attachment in the way described in section 4.4.1.
> >
> > The target of @appliesTo is all the composites in the domain - each
> > taken as a composite file and no more.
> > The exceptions are included composites - only the including
> > composites are targeted and then any including
> > is done before evaluating the @appliesTo.
> >
> > There is no humongous tree of composites made up by tracing through
> > <implementation.composite/>
> > elements.
> >
> > All that there is is a set of composites - the ones that are used in
> > the Domain.
> >
> > Each composite is taken separately and the XPath of @appliesTo is
> > run against that composite, with includes done
> > before the evaluation, if there are any includes.
> >
> >
> > Yours, Mike.
> >
> > Strategist - Emerging Technologies, SCA & SDO.
> > Co Chair OASIS SCA Assembly TC.
> > IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> > Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
> > Email: mike_edwards@uk.ibm.com
> >
>
> >
> > From:
> >
> > Raymond Feng <rfeng@us.ibm.com>
> >
> > To:
> >
> > ashok.malhotra@oracle.com
> >
> > Cc:
> >
> > OASIS Policy <sca-policy@lists.oasis-open.org>
> >
> > Date:
> >
> > 17/09/2009 00:23
> >
> > Subject:
> >
> > Re: [sca-policy] Further Thoughts on Issue 87
> >
> >
> >
> >
> >
> > I was assuming that "uri" is an attribute for the "component"
> > element. But even with that, we still have issues for the inner
> > composite. The following shows the domain composite and inner
> composite.
> >
> > [1]
> > <composite xmlns:ns2="_http://ns2_ <http://ns2/>" ...>
> > <component name="Component1" uri="Component1">
> > <implementation.composite name="ns2:InnerComposite"/>
> > </component>
> > </composite>
> >
> > Applying //component[@uri='Component1/Component2'] against the xml
> > still doesn't select Component2 as it is NOT an element in the tree.
> > If we inline the inner composite into the domain composite as
> > illustrated below, the it could work.
> >
> > [2]
> > <composite xmlns:ns2="_http://ns2_ <http://ns2/>" ...>
> > <component name="Component1" uri="Component1">
> > <implementation.composite name="ns2:InnerComposite">
> > <!-- For demo purpose, Inline the inner composite -->
> > <composite targetNamespace="_http://ns2_ <http://ns2/>"
> name="InnerComposite">
> > <service name="Service1" promote="Component2/Service1"/>
> > <reference name="ref1" promote="Component2/ref1"/>
> > <component name="Component2" uri="Component1/Component2">
> > <implementation.java class="sample.Component2Impl"/>
> > </component>
> > </composite>
> > </implementation.composite>
> > </component>
> > </composite>
> >
> > I'm arguing if we should take [2] instead of [1] as the info set to
> > apply the xpath.
> >
> > Thanks,
> > Raymond
> > Raymond Feng
> > Senior Software Engineer, Apache Tuscany PMC Member & Committer
> > IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster City, CA
> 94404, USA
> > E-mail: rfeng@us.ibm.com, Notes: Raymond Feng/Burlingame/IBM, Tel:
> > 650-645-8117, T/L: 367-8117
> > Apache Tuscany: _http://tuscany.apache.org_ <http://tuscany.apache.org/>
> > Co-author of Tuscany In Action: _http://www.manning.com/laws_
> >
> >
> > ashok malhotra <ashok.malhotra@oracle.com> wrote on 09/16/2009
> 01:31:20 PM:
> >
> > > From:
> > >
> > > ashok malhotra <ashok.malhotra@oracle.com>
> > >
> > > To:
> > >
> > > Raymond Feng/Burlingame/IBM@IBMUS
> > >
> > > Cc:
> > >
> > > OASIS Policy <sca-policy@lists.oasis-open.org>
> > >
> > > Date:
> > >
> > > 09/16/2009 01:33 PM
> > >
> > > Subject:
> > >
> > > Re: [sca-policy] Further Thoughts on Issue 87
> > >
> > > Hi Raymond:
> > > I think I understand your concern now.
> > > Although the Assembly spec defines a URI scheme to identify embedded
> > > composites, the URI
> > > does not appear as an attribute and, thus, cannot be used for
> selection.
> > > I believe we need to raise an issue against the Assembly spec. Do
> you
> > > want to do it or shall I raise it?
> > > All the best, Ashok
> > >
> > >
> > > Raymond Feng wrote:
> > > > If we look at the domain composite:
> > > >
> > > > <composite xmlns:ns2="_http://ns2_
> <http://ns2/> <_http://ns2/_>" ...>
> > > > <component name="Component1">
> > > > <implementation.composite
> name="ns2:InnerComposite"/>
> > > > </component>
> > > > </composite>
> > > >
> > > > Applying //component[@uri='Component1/Component2'] against the xml
> > > > document above won't find Component2. There are no component
> elements
> > > > in the XML tree whose uri attribute is 'Component1/Component2'.
> > > >
> > > > What I'm arguing is that the XML infoset for the domain composite
> > > > doesn't recursively go into the inner composite used for
> > > > "implementation.composite" because the inner composite is
> referenced
> > > > by a QName (similar with the include case, but the spec resolves
> that
> > > > by flattening the included composites first). The xpath only
> works if
> > > > we inline the inner composite by value as illustrated below:
> > > >
> > > > <composite xmlns:ns2="_http://ns2_ <http://ns2/> <_http://ns2/_>
> <_http://ns2/_>
> > > > <_http://ns2/_>" ...>
> > > > <component name="Component1">
> > > > <implementation.composite name="ns2:InnerComposite">
> > > > <!-- For demo purpose, Inline the inner composite -->
> > > > <composite targetNamespace="_http://ns2_
> <http://ns2/> <_http://ns2/_>"
> > > > name="InnerComposite">
> > > > <service name="Service1" promote="Component2/Service1"/>
> > > > <reference name="ref1" promote="Component2/ref1"/>
> > > > <component name="Component2">
> > > > <implementation.java
> class="sample.Component2Impl"/>
> > > > </component>
> > > > </composite>
> > > > </implementation.composite>
> > > > </component>
> > > > </composite>
> > > >
> > > > Thanks,
> > > > Raymond
> > > >
> ------------------------------------------------------------------------
> > > > *Raymond Feng*
> > > > Senior Software Engineer, Apache Tuscany PMC Member & Committer
> > > > /IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster
> City, CA
> > > > 94404, USA*
> > > > E-mail*//: //_rfeng@us.ibm.com_/ <_mailto:rfeng@us.ibm.com_>/,
> > > > *Notes*//: Raymond Feng/Burlingame/IBM, *Tel*//: 650-645-8117,
> > > > *T/L*//: 367-8117*
> > > > Apache Tuscany*//: //_http://tuscany.apache.org_/
> > > > <_http://tuscany.apache.org/_>/
> > > > Co-author of Tuscany In Action: //_http://www.manning.com/laws_// /
> > > >
> ------------------------------------------------------------------------
> > > >
> > > >
> > > > ashok malhotra <ashok.malhotra@oracle.com> wrote on 09/16/2009
> > > > 11:25:12 AM:
> > > >
> > > > > From:
> > > > >
> > > > > ashok malhotra <ashok.malhotra@oracle.com>
> > > > >
> > > > > To:
> > > > >
> > > > > Raymond Feng/Burlingame/IBM@IBMUS
> > > > >
> > > > > Cc:
> > > > >
> > > > > OASIS Policy <sca-policy@lists.oasis-open.org>
> > > > >
> > > > > Date:
> > > > >
> > > > > 09/16/2009 11:27 AM
> > > > >
> > > > > Subject:
> > > > >
> > > > > Re: [sca-policy] Further Thoughts on Issue 87
> > > > >
> > > > > Raymond:
> > > > > I checked the Assembly spec and I think the URI for Component2 is
> > > > > Component1/Component2
> > > > > Thus, //component[@uri='Component1/Component2']should find
> Component2
> > > > > provided
> > > > > the URI is surfaced as an attribute called URI.
> > > > >
> > > > > Is the problem "How to find a component given its URI" ?
> > > > >
> > > > > All the best, Ashok
> > > > >
> > > > >
> > > > > Raymond Feng wrote:
> > > > > > Do you mind giving me the xpath to select Component2 in my
> example?
> > > > > >
> > > > > >
> > > >
> ------------------------------------------------------------------------
> > > > > > *Raymond Feng*
> > > > > > Senior Software Engineer, Apache Tuscany PMC Member & Committer
> > > > > > /IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster
> City, CA
> > > > > > 94404, USA*
> > > > > > E-mail*//: //_rfeng@us.ibm.com_/ <_mailto:rfeng@us.ibm.com_>/,
> > > > > > *Notes*//: Raymond Feng/Burlingame/IBM, *Tel*//: 650-645-8117,
> > > > > > *T/L*//: 367-8117*
> > > > > > Apache Tuscany*//: //_http://tuscany.apache.org_/
> > > > > > <_http://tuscany.apache.org/_>/
> > > > > > Co-author of Tuscany In Action:
> //_http://www.manning.com/laws_// /
> > > > > >
> > > >
> ------------------------------------------------------------------------
> > > > > >
> > > > > >
> > > > > > ashok malhotra <ashok.malhotra@oracle.com> wrote on 09/16/2009
> > > > > > 09:11:35 AM:
> > > > > >
> > > > > > > From:
> > > > > > >
> > > > > > > ashok malhotra <ashok.malhotra@oracle.com>
> > > > > > >
> > > > > > > To:
> > > > > > >
> > > > > > > Raymond Feng/Burlingame/IBM@IBMUS
> > > > > > >
> > > > > > > Cc:
> > > > > > >
> > > > > > > OASIS Policy <sca-policy@lists.oasis-open.org>
> > > > > > >
> > > > > > > Date:
> > > > > > >
> > > > > > > 09/16/2009 09:13 AM
> > > > > > >
> > > > > > > Subject:
> > > > > > >
> > > > > > > Re: [sca-policy] Further Thoughts on Issue 87
> > > > > > >
> > > > > > > Raymond:
> > > > > > > Re. your example, the spec says:
> > > > > > > "Where the policySet is intended to be specific to a
> particular use
> > > > > > of a
> > > > > > > composite file (rather than to all uses of the composite), the
> > > > > > > structuralURI of a component is used to attach policySet to a
> > > > specific
> > > > > > > use of a nested component, as described in the SCA Assembly
> > > > > > > specification [SCA-Assembly]."
> > > > > > >
> > > > > > > Thus, the "structuralURI" of component2 must be used to
> refer to it.
> > > > > > > Is this unclear or are you not happy with the solution.
> > > > > > >
> > > > > > >
> > > > > > > All the best, Ashok
> > > > > > >
> > > > > > >
> > > > > > > Raymond Feng wrote:
> > > > > > > > Hi, Ashok.
> > > > > > > >
> > > > > > > > Thank you for sharing your thoughts. I'm running into
> similar
> > > > issues.
> > > > > > > > Please see my comments inline.
> > > > > > > >
> > > > > > > > Raymond
> > > > > > > >
> > > > > >
> > > >
> ------------------------------------------------------------------------
> > > > > > > > *Raymond Feng*
> > > > > > > > Senior Software Engineer, Apache Tuscany PMC Member &
> Committer
> > > > > > > > /IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster
> > > > City, CA
> > > > > > > > 94404, USA*
> > > > > > > > E-mail*//: //_rfeng@us.ibm.com_/
> <_mailto:rfeng@us.ibm.com_>/,
> > > > > > > > *Notes*//: Raymond Feng/Burlingame/IBM, *Tel*//:
> 650-645-8117,
> > > > > > > > *T/L*//: 367-8117*
> > > > > > > > Apache Tuscany*//: //_http://tuscany.apache.org_/
> > > > > > > > <_http://tuscany.apache.org/_>/
> > > > > > > > Co-author of Tuscany In Action:
> > > > //_http://www.manning.com/laws_// /
> > > > > > > >
> > > > > >
> > > >
> ------------------------------------------------------------------------
> > > > > > > >
> > > > > > > >
> > > > > > > > ashok malhotra <ashok.malhotra@oracle.com> wrote on
> 09/16/2009
> > > > > > > > 07:24:21 AM:
> > > > > > > >
> > > > > > > > > From:
> > > > > > > > >
> > > > > > > > > ashok malhotra <ashok.malhotra@oracle.com>
> > > > > > > > >
> > > > > > > > > To:
> > > > > > > > >
> > > > > > > > > OASIS Policy <sca-policy@lists.oasis-open.org>
> > > > > > > > >
> > > > > > > > > Date:
> > > > > > > > >
> > > > > > > > > 09/16/2009 07:26 AM
> > > > > > > > >
> > > > > > > > > Subject:
> > > > > > > > >
> > > > > > > > > [sca-policy] Further Thoughts on Issue 87
> > > > > > > > >
> > > > > > > > > Issue 87 was raised because the XPath syntax in the
> example
> > > > > > Snippet 3-5
> > > > > > > > > in section 3.4 was thought to be
> > > > > > > > > incorrect. On subsequent checking it turned out that the
> > > > syntax
> > > > > > was,
> > > > > > > > > indeed, correct.
> > > > > > > > > An XPath expression that consists of an unadorned
> element name
> > > > > > selects
> > > > > > > > > all element children of the
> > > > > > > > > context node with that name.
> > > > > > > >
> > > > > > > > You are right. The XPath that doesn't start with / is a
> > > > relative one.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > The spec (lines 457-458) says "Note that the XPath
> > > > expression will
> > > > > > > > > always be evaluated within the context of an attachment
> > > > considering
> > > > > > > > > elements where binding instances or implementations
> are allowed
> > > > > > to be
> > > > > > > > > present. The expression is evaluated against /the parent
> > > > element
> > > > > > of any
> > > > > > > > > binding or implementation element/."
> > > > > > > > >
> > > > > > > > > Thus, if a policySet is attached high at the component
> > > > level, its
> > > > > > > > > applicability needs to be examined against the parent
> element
> > > > > > > > > of any binding or implementation element. That is,
> the context
> > > > > > node is
> > > > > > > > > set, in turn to each such parent element and the XPath
> is then
> > > > > > > > > evaluated. This seems unduly onerous, so I suggested
> changing
> > > > > > the spec
> > > > > > > > > to say that the context node
> > > > > > > > > is the root of the SCDL document. An expression such as
> > > > > > //binding.ws
> > > > > > > > > would then select all binding.ws elements anywhere
> > > > > > > > > in the SCDL. This seems to me to be significantly
> simpler to
> > > > > > evaluate.
> > > > > > > > >
> > > > > > > > > Dave, pointed out that this would not cover included
> > > > composites and
> > > > > > > > that
> > > > > > > > > this was a problem.
> > > > > > > > >
> > > > > > > > > On further reflection, I realized that to evaluate the
> > > > @attachTp
> > > > > > in the
> > > > > > > > > case of external attachment we create an
> > > > > > > > > */Infoset for External Attachment/* See line 844.
> This does
> > > > > > cover the
> > > > > > > > > included composites and the @appliesTo in
> > > > > > > > > policySets could be evaluated using the root of this
> constructed
> > > > > > > > InfoSet
> > > > > > > > > as the context element.
> > > > > > > >
> > > > > > > > My understanding is that we use the domain composite as the
> > > > > > infoset to
> > > > > > > > apply the
> > > > > > > > xpath for @attchTo. All included composites have been
> merged
> > > > before
> > > > > > > > the evaluation.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > What do people think? Details of the construction of the
> > > > > > */Infoset for
> > > > > > > > > External Attachment/* are copied below for
> > > > > > > > > easy reference.
> > > > > > > > >
> > > > > > > > > 1. The Domain is treated as a special composite,
> with
> > > > a blank
> > > > > > > > name
> > > > > > > > > - ""
> > > > > > > > >
> > > > > > > > > 2. Where one composite includes one or more other
> > > > > > composites, it
> > > > > > > > > is the including composite which is addressed by the
> XPath
> > > > and its
> > > > > > > > > contents are the result of preprocessing all of the
> include
> > > > elements
> > > > > > > > >
> > > > > > > > > --Where the policySet is intended to be specific to a
> > > > > > particular
> > > > > > > > use
> > > > > > > > > of a composite file (rather than to all uses of the
> > > > > > composite), the
> > > > > > > > > structuralURI of a component is used to attach
> policySet to a
> > > > > > specific
> > > > > > > > > use of a nested component, as described in the SCA
> Assembly
> > > > > > > > > specification [SCA-Assembly].
> > > > > > > >
> > > > > > > > We need to clarify on the "implementation.composite" case.
> > > > Taking the
> > > > > > > > following example:
> > > > > > > >
> > > > > > > > Domain composite:
> > > > > > > > <composite xmlns:ns2="_http://ns2_
> <http://ns2/> <_http://ns2/_> <_http://ns2/_>
> > > > <_http://ns2/_>" ...>
> > > > > > > > <component name="Component1">
> > > > > > > > <implementation.composite
> > > > name="ns2:InnerComposite"/>
> > > > > > > > </component>
> > > > > > > > </composite>
> > > > > > > >
> > > > > > > > Inner Composite:
> > > > > > > > <composite targetNamespace="_http://ns2_
> <http://ns2/> <_http://ns2/_>
> > > > <_http://ns2/_> <_http://ns2/_>"
> > > > > > > > name="InnerComposite">
> > > > > > > > <service name="Service1"
> promote="Component2/Service1"/>
> > > > > > > > <reference name="ref1" promote="Component2/ref1"/>
> > > > > > > > <component name="Component2">
> > > > > > > > <implementation.java
> > > > class="sample.Component2Impl"/>
> > > > > > > > </component>
> > > > > > > > </composite>
> > > > > > > >
> > > > > > > > Please note that in the XML infoset of the domain
> composite, the
> > > > > > inner
> > > > > > > > composite is referenced by QName,
> > > > > > > > not by the value. That means the XML representation of
> the inner
> > > > > > > > composite is not part of the domain composite
> > > > > > > > document.
> > > > > > > >
> > > > > > > > How do we define the xpath to select the Component2 in
> this case?
> > > > > > > > Using the domain composite as the root, I don't think
> > > > > > > > //component[@uri='Component1/Component2'] will find any
> nodes.
> > > > > > > >
> > > > > > > > Do we expect the URIRef function to go beyond one single
> DOM
> > > > document?
> > > > > > > >
> > > > > > > > >
> > > > > > > > > --The XPath expression can make use of the unique
> URI to
> > > > > > indicate
> > > > > > > > > specific use instances, where different policySets
> need to be
> > > > > > used for
> > > > > > > > > those different instances.
> > > > > > > >
> > > > > > > > I think we should clearly define the signature of the XPath
> > > > functions
> > > > > > > > such as URIRef, IntentRef. It is not clear what return types
> > > > > > > > are in the current spec.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > All the best, Ashok
> > > > > > > > >
> > > > > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe from this mail list, you must leave the
> OASIS
> > > > TC that
> > > > > > > > > generates this mail. Follow this link to all your TCs in
> > > > OASIS at:
> > > > > > > > >
> > > > > >
> _https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
> > > > > > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this mail list, you must leave the OASIS TC that
> > > generates this mail. Follow this link to all your TCs in OASIS at:
> > >
> _https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php_
> > >
> >
> >
> >
> >
> >
>
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
> >
> >
> >
> >
>
>
>
>
> ------------------------------------------------------------------------
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU/
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]