You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Greg Dritschler <gr...@gmail.com> on 2008/03/06 18:20:55 UTC
Re: [Spec Related] 'provides' attribute in PolicySet
Venkat,
I was trying some stuff with policy sets and noticed the QName resolution
wasn't working as I expected. Specifically the targetNameSpace attribute of
the definitions.xml document doesn't appear to be used to form the QName of
the policy sets within. I recalled we had discussed this in this old
thread.
PolicySetProcessor does this:
policySet.setName(getQName(reader, NAME));
So it is trying to treat the @name attribute as a QName. I thought we had
concluded it is an NCName.
For comparison CompositeProcessor does this:
composite.setName(new QName(getString(reader, TARGET_NAMESPACE),
getString(reader, NAME)));
This is what I thought would happen based on this discussion.
On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Venkat,
>
> I was out on vacation when your original question was posted, so here's
> my contribution.
>
> Venkata Krishnan wrote:
> > Thanks Raymond. A few more questions ;-)
> >
> > - The xsd defines the name attribute for PolicyIntent and PolicySet as
> > of type NCName. However we have model these in the model classes
> > QNames. I am assuming that the namespace uri for all intents and
> > policyset defined in a specific definitions.xml is the value of the
> > 'targetNamespace' attribute of the 'definitions' element. Is this
> > right?
> >
>
> Typically, all declarations of name elements for elements which live in
> a particular namespace are defined in the XSDs as NCNames (see
> Composite, for example). It is usual for the targetNamespace to declare
> the namespace into which the elements are being declared.
>
> So, in this case for the intents & policySets, you're right, we'd expect
> the targetNamespace to be used. Anything else would look distinctly odd.
>
> > - Can a qualified intent have its qualifiable parent intent belonging
> > to a different targetnamespace. If so how would this be evident from
> > the name of the qualified intent? For example if there is an intent
> > a:intentOne and then there is a qualified intent over this like
> > intentOne.intentTwo - how is to be inferred that intentOne belongs to
> > a different namespace
> >
>
> Hmm, we had never intended this. I'd expect the qualified intent and its
> qualifiers to be in the same namespace. It's not outlawed for them to
> be in different namespaces, but I've no idea how you would express the
> definition to indicate this.
>
>
> > Thanks
> >
> > - Venkat
>
> Hope this helps,
>
> Yours, Mike.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [Spec Related] 'provides' attribute in PolicySet
Posted by Venkata Krishnan <fo...@gmail.com>.
I have fixed this under r634975.
Thanks
- Venkat
On Sat, Mar 8, 2008 at 3:33 PM, Venkata Krishnan <fo...@gmail.com>
wrote:
> Ok, I am going to fix this as follows : -
>
> - am keeping the name in the PolicyIntent and PolicySet model as QName and
> assign for the namespaceURI, the targetNamespace specified for the
> defintions.xml in question
> - elsewhere in the definitions.xml where the intents defined here are
> referenced, such as in Profile Intents or PolicySets, the intent names will
> be used in qualified form with an appropriate prefix that points to the
> targetnamespace.
>
> - Venkat
>
>
> On Sat, Mar 8, 2008 at 3:40 AM, Greg Dritschler <gr...@gmail.com>
> wrote:
>
> > See below.
> >
> > On Fri, Mar 7, 2008 at 12:11 PM, Venkata Krishnan <for.svkrish@gmail.com
> > >
> > wrote:
> >
> > > Thinking a bit futher about this, I am wondering what would we expect
> > for
> > > 'requires' attribute of a ProfileIntent. Do we assume that the
> > intents
> > > required by the Profile Intent should also belong to the same
> > namespace as
> > > the Profile Intent ? I guess not.
> > >
> >
> > Right. @requires takes a list of QNames so it can be composed of
> > intents in
> > various namespaces. I can see someone wanting to create a profile
> > intent in
> > their own namespace that uses intents in other standard namespaces.
> >
> >
> > >
> > > How about the case of the 'provides' attribute for PolicySets ? Do we
> > say
> > > these must be QNames strictly even if the PolicySet was just about
> > > providing
> > > for intents in the same namespace ?
> > >
> >
> > @provides is also a list of QNames so the usual rules for the prefix
> > should
> > be followed. If there is no prefix, then xmlns is used by default (not
> > targetNamespace). If you want @provides to refer to an intent that's
> > defined in the same definitions.xml, you need to define a namespace
> > prefix
> > for it (with the same value as targetNamespace) and use the prefix
> > appropriately.
> >
> >
> > >
> > > Am just about trying to understand if the targetnamespace is to be
> > applied
> > > only to Intent and PolicySet names and not to where they might be
> > > referrred
> > > within the same definitions.xml file.
> > >
> > > - Venkat
> > >
> > >
> > > On Fri, Mar 7, 2008 at 10:09 PM, Venkata Krishnan <
> > for.svkrish@gmail.com>
> > > wrote:
> > >
> > > > Ok. I seemed to have lost the plot down the line. Now that I have
> > > > re-read Mike's explanation in this thread, it does seem like you
> > have a
> > > > point.
> > > >
> > > > - Venkat
> > > >
> > > >
> > > > On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler <
> > > greg.dritschler@gmail.com>
> > > > wrote:
> > > >
> > > > > No. The type of @name is either NCName or QName. It cannot be
> > both.
> > > > > If it
> > > > > is an NCName, then it cannot have a namespace prefix; the
> > namespace
> > > is
> > > > > always the targetNamespace. If it is a QName, then it can have a
> > > > > namespace
> > > > > prefix; if it does not have a prefix then it uses the default
> > > namespace
> > > > > from xmlns. The spec says @name is a QName, but I thought from
> > the
> > > > > above
> > > > > discussion that we had concluded this is not correct and that it
> > > should
> > > > > be
> > > > > an NCName.
> > > > >
> > > > > On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan <
> > > for.svkrish@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Greg,
> > > > > >
> > > > > > Yes, it seems that when the PolicySet name is a NCName it does
> > not
> > > > > assume
> > > > > > the targetNamespace as its namespace. I shall fix this
> > rightaway.
> > > > > >
> > > > > > But then, I suppose its ok for a PolicySet name to be a QName
> > when
> > > it
> > > > > is
> > > > > > desired to have the PolicySet take a namespace other than the
> > > > > > targetNamespace. i.e. all policysets in a definitions.xml need
> > not
> > > > > belong
> > > > > > to
> > > > > > the same namespace. Do you share this thought ?
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > - Venkat
> > > > > >
> > > > > > If a PolicySet name does not have a prefix it assumes the
> > > > > targetNamespace.
> > > > > > If a
> > > > > >
> > > > > > On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler <
> > > > > > greg.dritschler@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Venkat,
> > > > > > >
> > > > > > > I was trying some stuff with policy sets and noticed the QName
> > > > > > resolution
> > > > > > > wasn't working as I expected. Specifically the
> > targetNameSpace
> > > > > > attribute
> > > > > > > of
> > > > > > > the definitions.xml document doesn't appear to be used to form
> > the
> > > > > QName
> > > > > > > of
> > > > > > > the policy sets within. I recalled we had discussed this in
> > this
> > > > > old
> > > > > > > thread.
> > > > > > >
> > > > > > > PolicySetProcessor does this:
> > > > > > > policySet.setName(getQName(reader, NAME));
> > > > > > >
> > > > > > > So it is trying to treat the @name attribute as a QName. I
> > > thought
> > > > > we
> > > > > > had
> > > > > > > concluded it is an NCName.
> > > > > > >
> > > > > > > For comparison CompositeProcessor does this:
> > > > > > > composite.setName(new QName(getString(reader,
> > TARGET_NAMESPACE),
> > > > > > > getString(reader, NAME)));
> > > > > > >
> > > > > > > This is what I thought would happen based on this discussion.
> > > > > > >
> > > > > > > On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards <
> > > > > > > mike.edwards.inglenook@gmail.com> wrote:
> > > > > > >
> > > > > > > > Venkat,
> > > > > > > >
> > > > > > > > I was out on vacation when your original question was
> > posted, so
> > > > > > here's
> > > > > > > > my contribution.
> > > > > > > >
> > > > > > > > Venkata Krishnan wrote:
> > > > > > > > > Thanks Raymond. A few more questions ;-)
> > > > > > > > >
> > > > > > > > > - The xsd defines the name attribute for PolicyIntent and
> > > > > PolicySet
> > > > > > as
> > > > > > > > > of type NCName. However we have model these in the model
> > > > > classes
> > > > > > > > > QNames. I am assuming that the namespace uri for all
> > intents
> > > > > and
> > > > > > > > > policyset defined in a specific definitions.xml is the
> > value
> > > of
> > > > > the
> > > > > > > > > 'targetNamespace' attribute of the 'definitions' element.
> > Is
> > > > > this
> > > > > > > > > right?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Typically, all declarations of name elements for elements
> > which
> > > > > live
> > > > > > in
> > > > > > > > a particular namespace are defined in the XSDs as NCNames
> > (see
> > > > > > > > Composite, for example). It is usual for the
> > targetNamespace to
> > > > > > declare
> > > > > > > > the namespace into which the elements are being declared.
> > > > > > > >
> > > > > > > > So, in this case for the intents & policySets, you're right,
> > > we'd
> > > > > > expect
> > > > > > > > the targetNamespace to be used. Anything else would look
> > > > > distinctly
> > > > > > > odd.
> > > > > > > >
> > > > > > > > > - Can a qualified intent have its qualifiable parent
> > intent
> > > > > > belonging
> > > > > > > > > to a different targetnamespace. If so how would this be
> > > evident
> > > > > > from
> > > > > > > > > the name of the qualified intent? For example if there is
> > an
> > > > > intent
> > > > > > > > > a:intentOne and then there is a qualified intent over this
> > > like
> > > > > > > > > intentOne.intentTwo - how is to be inferred that intentOne
> > > > > belongs
> > > > > > to
> > > > > > > > > a different namespace
> > > > > > > > >
> > > > > > > >
> > > > > > > > Hmm, we had never intended this. I'd expect the qualified
> > intent
> > > > > and
> > > > > > its
> > > > > > > > qualifiers to be in the same namespace. It's not outlawed
> > for
> > > > > them to
> > > > > > > > be in different namespaces, but I've no idea how you would
> > > express
> > > > > the
> > > > > > > > definition to indicate this.
> > > > > > > >
> > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > >
> > > > > > > > > - Venkat
> > > > > > > >
> > > > > > > > Hope this helps,
> > > > > > > >
> > > > > > > > Yours, Mike.
> > > > > > > >
> > > > > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> > tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail:
> > tuscany-dev-help@ws.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
>
Re: [Spec Related] 'provides' attribute in PolicySet
Posted by Venkata Krishnan <fo...@gmail.com>.
Ok, I am going to fix this as follows : -
- am keeping the name in the PolicyIntent and PolicySet model as QName and
assign for the namespaceURI, the targetNamespace specified for the
defintions.xml in question
- elsewhere in the definitions.xml where the intents defined here are
referenced, such as in Profile Intents or PolicySets, the intent names will
be used in qualified form with an appropriate prefix that points to the
targetnamespace.
- Venkat
On Sat, Mar 8, 2008 at 3:40 AM, Greg Dritschler <gr...@gmail.com>
wrote:
> See below.
>
> On Fri, Mar 7, 2008 at 12:11 PM, Venkata Krishnan <fo...@gmail.com>
> wrote:
>
> > Thinking a bit futher about this, I am wondering what would we expect
> for
> > 'requires' attribute of a ProfileIntent. Do we assume that the intents
> > required by the Profile Intent should also belong to the same namespace
> as
> > the Profile Intent ? I guess not.
> >
>
> Right. @requires takes a list of QNames so it can be composed of intents
> in
> various namespaces. I can see someone wanting to create a profile intent
> in
> their own namespace that uses intents in other standard namespaces.
>
>
> >
> > How about the case of the 'provides' attribute for PolicySets ? Do we
> say
> > these must be QNames strictly even if the PolicySet was just about
> > providing
> > for intents in the same namespace ?
> >
>
> @provides is also a list of QNames so the usual rules for the prefix
> should
> be followed. If there is no prefix, then xmlns is used by default (not
> targetNamespace). If you want @provides to refer to an intent that's
> defined in the same definitions.xml, you need to define a namespace prefix
> for it (with the same value as targetNamespace) and use the prefix
> appropriately.
>
>
> >
> > Am just about trying to understand if the targetnamespace is to be
> applied
> > only to Intent and PolicySet names and not to where they might be
> > referrred
> > within the same definitions.xml file.
> >
> > - Venkat
> >
> >
> > On Fri, Mar 7, 2008 at 10:09 PM, Venkata Krishnan <for.svkrish@gmail.com
> >
> > wrote:
> >
> > > Ok. I seemed to have lost the plot down the line. Now that I have
> > > re-read Mike's explanation in this thread, it does seem like you have
> a
> > > point.
> > >
> > > - Venkat
> > >
> > >
> > > On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler <
> > greg.dritschler@gmail.com>
> > > wrote:
> > >
> > > > No. The type of @name is either NCName or QName. It cannot be
> both.
> > > > If it
> > > > is an NCName, then it cannot have a namespace prefix; the namespace
> > is
> > > > always the targetNamespace. If it is a QName, then it can have a
> > > > namespace
> > > > prefix; if it does not have a prefix then it uses the default
> > namespace
> > > > from xmlns. The spec says @name is a QName, but I thought from the
> > > > above
> > > > discussion that we had concluded this is not correct and that it
> > should
> > > > be
> > > > an NCName.
> > > >
> > > > On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan <
> > for.svkrish@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Greg,
> > > > >
> > > > > Yes, it seems that when the PolicySet name is a NCName it does not
> > > > assume
> > > > > the targetNamespace as its namespace. I shall fix this rightaway.
> > > > >
> > > > > But then, I suppose its ok for a PolicySet name to be a QName when
> > it
> > > > is
> > > > > desired to have the PolicySet take a namespace other than the
> > > > > targetNamespace. i.e. all policysets in a definitions.xml need not
> > > > belong
> > > > > to
> > > > > the same namespace. Do you share this thought ?
> > > > >
> > > > > Thanks
> > > > >
> > > > > - Venkat
> > > > >
> > > > > If a PolicySet name does not have a prefix it assumes the
> > > > targetNamespace.
> > > > > If a
> > > > >
> > > > > On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler <
> > > > > greg.dritschler@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Venkat,
> > > > > >
> > > > > > I was trying some stuff with policy sets and noticed the QName
> > > > > resolution
> > > > > > wasn't working as I expected. Specifically the targetNameSpace
> > > > > attribute
> > > > > > of
> > > > > > the definitions.xml document doesn't appear to be used to form
> the
> > > > QName
> > > > > > of
> > > > > > the policy sets within. I recalled we had discussed this in
> this
> > > > old
> > > > > > thread.
> > > > > >
> > > > > > PolicySetProcessor does this:
> > > > > > policySet.setName(getQName(reader, NAME));
> > > > > >
> > > > > > So it is trying to treat the @name attribute as a QName. I
> > thought
> > > > we
> > > > > had
> > > > > > concluded it is an NCName.
> > > > > >
> > > > > > For comparison CompositeProcessor does this:
> > > > > > composite.setName(new QName(getString(reader,
> TARGET_NAMESPACE),
> > > > > > getString(reader, NAME)));
> > > > > >
> > > > > > This is what I thought would happen based on this discussion.
> > > > > >
> > > > > > On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards <
> > > > > > mike.edwards.inglenook@gmail.com> wrote:
> > > > > >
> > > > > > > Venkat,
> > > > > > >
> > > > > > > I was out on vacation when your original question was posted,
> so
> > > > > here's
> > > > > > > my contribution.
> > > > > > >
> > > > > > > Venkata Krishnan wrote:
> > > > > > > > Thanks Raymond. A few more questions ;-)
> > > > > > > >
> > > > > > > > - The xsd defines the name attribute for PolicyIntent and
> > > > PolicySet
> > > > > as
> > > > > > > > of type NCName. However we have model these in the model
> > > > classes
> > > > > > > > QNames. I am assuming that the namespace uri for all
> intents
> > > > and
> > > > > > > > policyset defined in a specific definitions.xml is the value
> > of
> > > > the
> > > > > > > > 'targetNamespace' attribute of the 'definitions' element.
> Is
> > > > this
> > > > > > > > right?
> > > > > > > >
> > > > > > >
> > > > > > > Typically, all declarations of name elements for elements
> which
> > > > live
> > > > > in
> > > > > > > a particular namespace are defined in the XSDs as NCNames (see
> > > > > > > Composite, for example). It is usual for the targetNamespace
> to
> > > > > declare
> > > > > > > the namespace into which the elements are being declared.
> > > > > > >
> > > > > > > So, in this case for the intents & policySets, you're right,
> > we'd
> > > > > expect
> > > > > > > the targetNamespace to be used. Anything else would look
> > > > distinctly
> > > > > > odd.
> > > > > > >
> > > > > > > > - Can a qualified intent have its qualifiable parent intent
> > > > > belonging
> > > > > > > > to a different targetnamespace. If so how would this be
> > evident
> > > > > from
> > > > > > > > the name of the qualified intent? For example if there is
> an
> > > > intent
> > > > > > > > a:intentOne and then there is a qualified intent over this
> > like
> > > > > > > > intentOne.intentTwo - how is to be inferred that intentOne
> > > > belongs
> > > > > to
> > > > > > > > a different namespace
> > > > > > > >
> > > > > > >
> > > > > > > Hmm, we had never intended this. I'd expect the qualified
> intent
> > > > and
> > > > > its
> > > > > > > qualifiers to be in the same namespace. It's not outlawed for
> > > > them to
> > > > > > > be in different namespaces, but I've no idea how you would
> > express
> > > > the
> > > > > > > definition to indicate this.
> > > > > > >
> > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > - Venkat
> > > > > > >
> > > > > > > Hope this helps,
> > > > > > >
> > > > > > > Yours, Mike.
> > > > > > >
> > > > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Re: [Spec Related] 'provides' attribute in PolicySet
Posted by Greg Dritschler <gr...@gmail.com>.
See below.
On Fri, Mar 7, 2008 at 12:11 PM, Venkata Krishnan <fo...@gmail.com>
wrote:
> Thinking a bit futher about this, I am wondering what would we expect for
> 'requires' attribute of a ProfileIntent. Do we assume that the intents
> required by the Profile Intent should also belong to the same namespace as
> the Profile Intent ? I guess not.
>
Right. @requires takes a list of QNames so it can be composed of intents in
various namespaces. I can see someone wanting to create a profile intent in
their own namespace that uses intents in other standard namespaces.
>
> How about the case of the 'provides' attribute for PolicySets ? Do we say
> these must be QNames strictly even if the PolicySet was just about
> providing
> for intents in the same namespace ?
>
@provides is also a list of QNames so the usual rules for the prefix should
be followed. If there is no prefix, then xmlns is used by default (not
targetNamespace). If you want @provides to refer to an intent that's
defined in the same definitions.xml, you need to define a namespace prefix
for it (with the same value as targetNamespace) and use the prefix
appropriately.
>
> Am just about trying to understand if the targetnamespace is to be applied
> only to Intent and PolicySet names and not to where they might be
> referrred
> within the same definitions.xml file.
>
> - Venkat
>
>
> On Fri, Mar 7, 2008 at 10:09 PM, Venkata Krishnan <fo...@gmail.com>
> wrote:
>
> > Ok. I seemed to have lost the plot down the line. Now that I have
> > re-read Mike's explanation in this thread, it does seem like you have a
> > point.
> >
> > - Venkat
> >
> >
> > On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler <
> greg.dritschler@gmail.com>
> > wrote:
> >
> > > No. The type of @name is either NCName or QName. It cannot be both.
> > > If it
> > > is an NCName, then it cannot have a namespace prefix; the namespace
> is
> > > always the targetNamespace. If it is a QName, then it can have a
> > > namespace
> > > prefix; if it does not have a prefix then it uses the default
> namespace
> > > from xmlns. The spec says @name is a QName, but I thought from the
> > > above
> > > discussion that we had concluded this is not correct and that it
> should
> > > be
> > > an NCName.
> > >
> > > On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan <
> for.svkrish@gmail.com>
> > > wrote:
> > >
> > > > Hi Greg,
> > > >
> > > > Yes, it seems that when the PolicySet name is a NCName it does not
> > > assume
> > > > the targetNamespace as its namespace. I shall fix this rightaway.
> > > >
> > > > But then, I suppose its ok for a PolicySet name to be a QName when
> it
> > > is
> > > > desired to have the PolicySet take a namespace other than the
> > > > targetNamespace. i.e. all policysets in a definitions.xml need not
> > > belong
> > > > to
> > > > the same namespace. Do you share this thought ?
> > > >
> > > > Thanks
> > > >
> > > > - Venkat
> > > >
> > > > If a PolicySet name does not have a prefix it assumes the
> > > targetNamespace.
> > > > If a
> > > >
> > > > On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler <
> > > > greg.dritschler@gmail.com>
> > > > wrote:
> > > >
> > > > > Venkat,
> > > > >
> > > > > I was trying some stuff with policy sets and noticed the QName
> > > > resolution
> > > > > wasn't working as I expected. Specifically the targetNameSpace
> > > > attribute
> > > > > of
> > > > > the definitions.xml document doesn't appear to be used to form the
> > > QName
> > > > > of
> > > > > the policy sets within. I recalled we had discussed this in this
> > > old
> > > > > thread.
> > > > >
> > > > > PolicySetProcessor does this:
> > > > > policySet.setName(getQName(reader, NAME));
> > > > >
> > > > > So it is trying to treat the @name attribute as a QName. I
> thought
> > > we
> > > > had
> > > > > concluded it is an NCName.
> > > > >
> > > > > For comparison CompositeProcessor does this:
> > > > > composite.setName(new QName(getString(reader, TARGET_NAMESPACE),
> > > > > getString(reader, NAME)));
> > > > >
> > > > > This is what I thought would happen based on this discussion.
> > > > >
> > > > > On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards <
> > > > > mike.edwards.inglenook@gmail.com> wrote:
> > > > >
> > > > > > Venkat,
> > > > > >
> > > > > > I was out on vacation when your original question was posted, so
> > > > here's
> > > > > > my contribution.
> > > > > >
> > > > > > Venkata Krishnan wrote:
> > > > > > > Thanks Raymond. A few more questions ;-)
> > > > > > >
> > > > > > > - The xsd defines the name attribute for PolicyIntent and
> > > PolicySet
> > > > as
> > > > > > > of type NCName. However we have model these in the model
> > > classes
> > > > > > > QNames. I am assuming that the namespace uri for all intents
> > > and
> > > > > > > policyset defined in a specific definitions.xml is the value
> of
> > > the
> > > > > > > 'targetNamespace' attribute of the 'definitions' element. Is
> > > this
> > > > > > > right?
> > > > > > >
> > > > > >
> > > > > > Typically, all declarations of name elements for elements which
> > > live
> > > > in
> > > > > > a particular namespace are defined in the XSDs as NCNames (see
> > > > > > Composite, for example). It is usual for the targetNamespace to
> > > > declare
> > > > > > the namespace into which the elements are being declared.
> > > > > >
> > > > > > So, in this case for the intents & policySets, you're right,
> we'd
> > > > expect
> > > > > > the targetNamespace to be used. Anything else would look
> > > distinctly
> > > > > odd.
> > > > > >
> > > > > > > - Can a qualified intent have its qualifiable parent intent
> > > > belonging
> > > > > > > to a different targetnamespace. If so how would this be
> evident
> > > > from
> > > > > > > the name of the qualified intent? For example if there is an
> > > intent
> > > > > > > a:intentOne and then there is a qualified intent over this
> like
> > > > > > > intentOne.intentTwo - how is to be inferred that intentOne
> > > belongs
> > > > to
> > > > > > > a different namespace
> > > > > > >
> > > > > >
> > > > > > Hmm, we had never intended this. I'd expect the qualified intent
> > > and
> > > > its
> > > > > > qualifiers to be in the same namespace. It's not outlawed for
> > > them to
> > > > > > be in different namespaces, but I've no idea how you would
> express
> > > the
> > > > > > definition to indicate this.
> > > > > >
> > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > - Venkat
> > > > > >
> > > > > > Hope this helps,
> > > > > >
> > > > > > Yours, Mike.
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
>
Re: [Spec Related] 'provides' attribute in PolicySet
Posted by Venkata Krishnan <fo...@gmail.com>.
Thinking a bit futher about this, I am wondering what would we expect for
'requires' attribute of a ProfileIntent. Do we assume that the intents
required by the Profile Intent should also belong to the same namespace as
the Profile Intent ? I guess not.
How about the case of the 'provides' attribute for PolicySets ? Do we say
these must be QNames strictly even if the PolicySet was just about providing
for intents in the same namespace ?
Am just about trying to understand if the targetnamespace is to be applied
only to Intent and PolicySet names and not to where they might be referrred
within the same definitions.xml file.
- Venkat
On Fri, Mar 7, 2008 at 10:09 PM, Venkata Krishnan <fo...@gmail.com>
wrote:
> Ok. I seemed to have lost the plot down the line. Now that I have
> re-read Mike's explanation in this thread, it does seem like you have a
> point.
>
> - Venkat
>
>
> On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler <gr...@gmail.com>
> wrote:
>
> > No. The type of @name is either NCName or QName. It cannot be both.
> > If it
> > is an NCName, then it cannot have a namespace prefix; the namespace is
> > always the targetNamespace. If it is a QName, then it can have a
> > namespace
> > prefix; if it does not have a prefix then it uses the default namespace
> > from xmlns. The spec says @name is a QName, but I thought from the
> > above
> > discussion that we had concluded this is not correct and that it should
> > be
> > an NCName.
> >
> > On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan <fo...@gmail.com>
> > wrote:
> >
> > > Hi Greg,
> > >
> > > Yes, it seems that when the PolicySet name is a NCName it does not
> > assume
> > > the targetNamespace as its namespace. I shall fix this rightaway.
> > >
> > > But then, I suppose its ok for a PolicySet name to be a QName when it
> > is
> > > desired to have the PolicySet take a namespace other than the
> > > targetNamespace. i.e. all policysets in a definitions.xml need not
> > belong
> > > to
> > > the same namespace. Do you share this thought ?
> > >
> > > Thanks
> > >
> > > - Venkat
> > >
> > > If a PolicySet name does not have a prefix it assumes the
> > targetNamespace.
> > > If a
> > >
> > > On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler <
> > > greg.dritschler@gmail.com>
> > > wrote:
> > >
> > > > Venkat,
> > > >
> > > > I was trying some stuff with policy sets and noticed the QName
> > > resolution
> > > > wasn't working as I expected. Specifically the targetNameSpace
> > > attribute
> > > > of
> > > > the definitions.xml document doesn't appear to be used to form the
> > QName
> > > > of
> > > > the policy sets within. I recalled we had discussed this in this
> > old
> > > > thread.
> > > >
> > > > PolicySetProcessor does this:
> > > > policySet.setName(getQName(reader, NAME));
> > > >
> > > > So it is trying to treat the @name attribute as a QName. I thought
> > we
> > > had
> > > > concluded it is an NCName.
> > > >
> > > > For comparison CompositeProcessor does this:
> > > > composite.setName(new QName(getString(reader, TARGET_NAMESPACE),
> > > > getString(reader, NAME)));
> > > >
> > > > This is what I thought would happen based on this discussion.
> > > >
> > > > On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards <
> > > > mike.edwards.inglenook@gmail.com> wrote:
> > > >
> > > > > Venkat,
> > > > >
> > > > > I was out on vacation when your original question was posted, so
> > > here's
> > > > > my contribution.
> > > > >
> > > > > Venkata Krishnan wrote:
> > > > > > Thanks Raymond. A few more questions ;-)
> > > > > >
> > > > > > - The xsd defines the name attribute for PolicyIntent and
> > PolicySet
> > > as
> > > > > > of type NCName. However we have model these in the model
> > classes
> > > > > > QNames. I am assuming that the namespace uri for all intents
> > and
> > > > > > policyset defined in a specific definitions.xml is the value of
> > the
> > > > > > 'targetNamespace' attribute of the 'definitions' element. Is
> > this
> > > > > > right?
> > > > > >
> > > > >
> > > > > Typically, all declarations of name elements for elements which
> > live
> > > in
> > > > > a particular namespace are defined in the XSDs as NCNames (see
> > > > > Composite, for example). It is usual for the targetNamespace to
> > > declare
> > > > > the namespace into which the elements are being declared.
> > > > >
> > > > > So, in this case for the intents & policySets, you're right, we'd
> > > expect
> > > > > the targetNamespace to be used. Anything else would look
> > distinctly
> > > > odd.
> > > > >
> > > > > > - Can a qualified intent have its qualifiable parent intent
> > > belonging
> > > > > > to a different targetnamespace. If so how would this be evident
> > > from
> > > > > > the name of the qualified intent? For example if there is an
> > intent
> > > > > > a:intentOne and then there is a qualified intent over this like
> > > > > > intentOne.intentTwo - how is to be inferred that intentOne
> > belongs
> > > to
> > > > > > a different namespace
> > > > > >
> > > > >
> > > > > Hmm, we had never intended this. I'd expect the qualified intent
> > and
> > > its
> > > > > qualifiers to be in the same namespace. It's not outlawed for
> > them to
> > > > > be in different namespaces, but I've no idea how you would express
> > the
> > > > > definition to indicate this.
> > > > >
> > > > >
> > > > > > Thanks
> > > > > >
> > > > > > - Venkat
> > > > >
> > > > > Hope this helps,
> > > > >
> > > > > Yours, Mike.
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
>
Re: [Spec Related] 'provides' attribute in PolicySet
Posted by Venkata Krishnan <fo...@gmail.com>.
Ok. I seemed to have lost the plot down the line. Now that I have re-read
Mike's explanation in this thread, it does seem like you have a point.
- Venkat
On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler <gr...@gmail.com>
wrote:
> No. The type of @name is either NCName or QName. It cannot be both. If
> it
> is an NCName, then it cannot have a namespace prefix; the namespace is
> always the targetNamespace. If it is a QName, then it can have a
> namespace
> prefix; if it does not have a prefix then it uses the default namespace
> from xmlns. The spec says @name is a QName, but I thought from the above
> discussion that we had concluded this is not correct and that it should be
> an NCName.
>
> On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan <fo...@gmail.com>
> wrote:
>
> > Hi Greg,
> >
> > Yes, it seems that when the PolicySet name is a NCName it does not
> assume
> > the targetNamespace as its namespace. I shall fix this rightaway.
> >
> > But then, I suppose its ok for a PolicySet name to be a QName when it is
> > desired to have the PolicySet take a namespace other than the
> > targetNamespace. i.e. all policysets in a definitions.xml need not
> belong
> > to
> > the same namespace. Do you share this thought ?
> >
> > Thanks
> >
> > - Venkat
> >
> > If a PolicySet name does not have a prefix it assumes the
> targetNamespace.
> > If a
> >
> > On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler <
> > greg.dritschler@gmail.com>
> > wrote:
> >
> > > Venkat,
> > >
> > > I was trying some stuff with policy sets and noticed the QName
> > resolution
> > > wasn't working as I expected. Specifically the targetNameSpace
> > attribute
> > > of
> > > the definitions.xml document doesn't appear to be used to form the
> QName
> > > of
> > > the policy sets within. I recalled we had discussed this in this old
> > > thread.
> > >
> > > PolicySetProcessor does this:
> > > policySet.setName(getQName(reader, NAME));
> > >
> > > So it is trying to treat the @name attribute as a QName. I thought we
> > had
> > > concluded it is an NCName.
> > >
> > > For comparison CompositeProcessor does this:
> > > composite.setName(new QName(getString(reader, TARGET_NAMESPACE),
> > > getString(reader, NAME)));
> > >
> > > This is what I thought would happen based on this discussion.
> > >
> > > On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards <
> > > mike.edwards.inglenook@gmail.com> wrote:
> > >
> > > > Venkat,
> > > >
> > > > I was out on vacation when your original question was posted, so
> > here's
> > > > my contribution.
> > > >
> > > > Venkata Krishnan wrote:
> > > > > Thanks Raymond. A few more questions ;-)
> > > > >
> > > > > - The xsd defines the name attribute for PolicyIntent and
> PolicySet
> > as
> > > > > of type NCName. However we have model these in the model classes
> > > > > QNames. I am assuming that the namespace uri for all intents and
> > > > > policyset defined in a specific definitions.xml is the value of
> the
> > > > > 'targetNamespace' attribute of the 'definitions' element. Is this
> > > > > right?
> > > > >
> > > >
> > > > Typically, all declarations of name elements for elements which live
> > in
> > > > a particular namespace are defined in the XSDs as NCNames (see
> > > > Composite, for example). It is usual for the targetNamespace to
> > declare
> > > > the namespace into which the elements are being declared.
> > > >
> > > > So, in this case for the intents & policySets, you're right, we'd
> > expect
> > > > the targetNamespace to be used. Anything else would look distinctly
> > > odd.
> > > >
> > > > > - Can a qualified intent have its qualifiable parent intent
> > belonging
> > > > > to a different targetnamespace. If so how would this be evident
> > from
> > > > > the name of the qualified intent? For example if there is an
> intent
> > > > > a:intentOne and then there is a qualified intent over this like
> > > > > intentOne.intentTwo - how is to be inferred that intentOne belongs
> > to
> > > > > a different namespace
> > > > >
> > > >
> > > > Hmm, we had never intended this. I'd expect the qualified intent and
> > its
> > > > qualifiers to be in the same namespace. It's not outlawed for them
> to
> > > > be in different namespaces, but I've no idea how you would express
> the
> > > > definition to indicate this.
> > > >
> > > >
> > > > > Thanks
> > > > >
> > > > > - Venkat
> > > >
> > > > Hope this helps,
> > > >
> > > > Yours, Mike.
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> >
>
Re: [Spec Related] 'provides' attribute in PolicySet
Posted by Greg Dritschler <gr...@gmail.com>.
No. The type of @name is either NCName or QName. It cannot be both. If it
is an NCName, then it cannot have a namespace prefix; the namespace is
always the targetNamespace. If it is a QName, then it can have a namespace
prefix; if it does not have a prefix then it uses the default namespace
from xmlns. The spec says @name is a QName, but I thought from the above
discussion that we had concluded this is not correct and that it should be
an NCName.
On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan <fo...@gmail.com>
wrote:
> Hi Greg,
>
> Yes, it seems that when the PolicySet name is a NCName it does not assume
> the targetNamespace as its namespace. I shall fix this rightaway.
>
> But then, I suppose its ok for a PolicySet name to be a QName when it is
> desired to have the PolicySet take a namespace other than the
> targetNamespace. i.e. all policysets in a definitions.xml need not belong
> to
> the same namespace. Do you share this thought ?
>
> Thanks
>
> - Venkat
>
> If a PolicySet name does not have a prefix it assumes the targetNamespace.
> If a
>
> On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler <
> greg.dritschler@gmail.com>
> wrote:
>
> > Venkat,
> >
> > I was trying some stuff with policy sets and noticed the QName
> resolution
> > wasn't working as I expected. Specifically the targetNameSpace
> attribute
> > of
> > the definitions.xml document doesn't appear to be used to form the QName
> > of
> > the policy sets within. I recalled we had discussed this in this old
> > thread.
> >
> > PolicySetProcessor does this:
> > policySet.setName(getQName(reader, NAME));
> >
> > So it is trying to treat the @name attribute as a QName. I thought we
> had
> > concluded it is an NCName.
> >
> > For comparison CompositeProcessor does this:
> > composite.setName(new QName(getString(reader, TARGET_NAMESPACE),
> > getString(reader, NAME)));
> >
> > This is what I thought would happen based on this discussion.
> >
> > On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards <
> > mike.edwards.inglenook@gmail.com> wrote:
> >
> > > Venkat,
> > >
> > > I was out on vacation when your original question was posted, so
> here's
> > > my contribution.
> > >
> > > Venkata Krishnan wrote:
> > > > Thanks Raymond. A few more questions ;-)
> > > >
> > > > - The xsd defines the name attribute for PolicyIntent and PolicySet
> as
> > > > of type NCName. However we have model these in the model classes
> > > > QNames. I am assuming that the namespace uri for all intents and
> > > > policyset defined in a specific definitions.xml is the value of the
> > > > 'targetNamespace' attribute of the 'definitions' element. Is this
> > > > right?
> > > >
> > >
> > > Typically, all declarations of name elements for elements which live
> in
> > > a particular namespace are defined in the XSDs as NCNames (see
> > > Composite, for example). It is usual for the targetNamespace to
> declare
> > > the namespace into which the elements are being declared.
> > >
> > > So, in this case for the intents & policySets, you're right, we'd
> expect
> > > the targetNamespace to be used. Anything else would look distinctly
> > odd.
> > >
> > > > - Can a qualified intent have its qualifiable parent intent
> belonging
> > > > to a different targetnamespace. If so how would this be evident
> from
> > > > the name of the qualified intent? For example if there is an intent
> > > > a:intentOne and then there is a qualified intent over this like
> > > > intentOne.intentTwo - how is to be inferred that intentOne belongs
> to
> > > > a different namespace
> > > >
> > >
> > > Hmm, we had never intended this. I'd expect the qualified intent and
> its
> > > qualifiers to be in the same namespace. It's not outlawed for them to
> > > be in different namespaces, but I've no idea how you would express the
> > > definition to indicate this.
> > >
> > >
> > > > Thanks
> > > >
> > > > - Venkat
> > >
> > > Hope this helps,
> > >
> > > Yours, Mike.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
Re: [Spec Related] 'provides' attribute in PolicySet
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Greg,
Yes, it seems that when the PolicySet name is a NCName it does not assume
the targetNamespace as its namespace. I shall fix this rightaway.
But then, I suppose its ok for a PolicySet name to be a QName when it is
desired to have the PolicySet take a namespace other than the
targetNamespace. i.e. all policysets in a definitions.xml need not belong to
the same namespace. Do you share this thought ?
Thanks
- Venkat
If a PolicySet name does not have a prefix it assumes the targetNamespace.
If a
On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler <gr...@gmail.com>
wrote:
> Venkat,
>
> I was trying some stuff with policy sets and noticed the QName resolution
> wasn't working as I expected. Specifically the targetNameSpace attribute
> of
> the definitions.xml document doesn't appear to be used to form the QName
> of
> the policy sets within. I recalled we had discussed this in this old
> thread.
>
> PolicySetProcessor does this:
> policySet.setName(getQName(reader, NAME));
>
> So it is trying to treat the @name attribute as a QName. I thought we had
> concluded it is an NCName.
>
> For comparison CompositeProcessor does this:
> composite.setName(new QName(getString(reader, TARGET_NAMESPACE),
> getString(reader, NAME)));
>
> This is what I thought would happen based on this discussion.
>
> On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards <
> mike.edwards.inglenook@gmail.com> wrote:
>
> > Venkat,
> >
> > I was out on vacation when your original question was posted, so here's
> > my contribution.
> >
> > Venkata Krishnan wrote:
> > > Thanks Raymond. A few more questions ;-)
> > >
> > > - The xsd defines the name attribute for PolicyIntent and PolicySet as
> > > of type NCName. However we have model these in the model classes
> > > QNames. I am assuming that the namespace uri for all intents and
> > > policyset defined in a specific definitions.xml is the value of the
> > > 'targetNamespace' attribute of the 'definitions' element. Is this
> > > right?
> > >
> >
> > Typically, all declarations of name elements for elements which live in
> > a particular namespace are defined in the XSDs as NCNames (see
> > Composite, for example). It is usual for the targetNamespace to declare
> > the namespace into which the elements are being declared.
> >
> > So, in this case for the intents & policySets, you're right, we'd expect
> > the targetNamespace to be used. Anything else would look distinctly
> odd.
> >
> > > - Can a qualified intent have its qualifiable parent intent belonging
> > > to a different targetnamespace. If so how would this be evident from
> > > the name of the qualified intent? For example if there is an intent
> > > a:intentOne and then there is a qualified intent over this like
> > > intentOne.intentTwo - how is to be inferred that intentOne belongs to
> > > a different namespace
> > >
> >
> > Hmm, we had never intended this. I'd expect the qualified intent and its
> > qualifiers to be in the same namespace. It's not outlawed for them to
> > be in different namespaces, but I've no idea how you would express the
> > definition to indicate this.
> >
> >
> > > Thanks
> > >
> > > - Venkat
> >
> > Hope this helps,
> >
> > Yours, Mike.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>