I have fixed this under r634975.
Thanks
- Venkat
On Sat, Mar 8, 2008 at 3:33 PM, Venkata Krishnan <[EMAIL PROTECTED]>
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 targetNames
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
See below.
On Fri, Mar 7, 2008 at 12:11 PM, Venkata Krishnan <[EMAIL PROTECTED]>
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
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' attri
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 <[EMAIL PROTECTED]>
wrote:
> No. The type of @name is either NCName or QName. It cannot be
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
f
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
targetNamesp
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 th
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
The policy framework spec says the @name attribute is a QName and even gives
an example where the namespace prefix is used:
Protect messages from unauthorized reading or
modification.
It is ambiguous to me whether 'acme' can refer to
ks,
> Raymond
>
> - Original Message -
> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
> To:
> Sent: Tuesday, July 31, 2007 7:24 AM
> Subject: [Spec Related] 'provides' attribute in PolicySet
>
>
> > Hi,
> >
> > In the spe
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, July 31, 2007 7:24 AM
Subject: [Spec Related] 'provides' attribute in PolicySet
Hi,
In the specs for the PolicyFwk, the xsds mention the 'provides'
attribute for a 'policySet' as optiona
Hi,
In the specs for the PolicyFwk, the xsds mention the 'provides'
attribute for a 'policySet' as optional. If this attribute is not
specified how does one figure out which intent a particular policySet
actually provides for. Could somebody help me with clarity on this,
please?
Thanks
- Venk
13 matches
Mail list logo
