Re: [Spec Related] 'provides' attribute in PolicySet
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 [EMAIL PROTECTED] wrote: 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 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [Spec Related] 'provides' attribute in PolicySet
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 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 [EMAIL PROTECTED] wrote: 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 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: Venkat, I was out on vacation when your original question was posted, so here's my contribution. Venkata
Re: [Spec Related] 'provides' attribute in PolicySet
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
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 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
Re: [Spec Related] 'provides' attribute in PolicySet
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 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
The policy framework spec says the @name attribute is a QName and even gives an example where the namespace prefix is used: intent name=acme:messageProtection constrains=sca:binding requires=confidentiality integrity description Protect messages from unauthorized reading or modification. /description /intent It is ambiguous to me whether 'acme' can refer to a different namespace than the targetNamespace. However in my mind it seems conceptually wrong to construct a definitions.xml file with a given targetNamespace and then make definitions for another namespace. I don't think there's a clear way to define qualifiers in one namespace that extend intents in another namespace.
Re: [Spec Related] 'provides' attribute in PolicySet
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? - 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 Thanks - Venkat On 7/31/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, AFAIK, policySet can be used directly without going through intents. So a policySet is still valid even it doesn't provide any intents. Please see the SCA Policy Framework Spec V1.0 starting from line 529: 529 Similarly, one or more policySets can be attached to any SCA element used in the definition of 530 components and composites. The attachment is specified by using the optional @policySets 531 attribute. This attribute takes as its value a list of policySet names. 532 For example, 533 534 service or reference. 535 binding.binding-type policySets=listOfQNames 536 /binding.binding-type. 537 /service or /reference ... Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org 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 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 - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Spec Related] 'provides' attribute in PolicySet
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 - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
Hi, AFAIK, policySet can be used directly without going through intents. So a policySet is still valid even it doesn't provide any intents. Please see the SCA Policy Framework Spec V1.0 starting from line 529: 529 Similarly, one or more policySets can be attached to any SCA element used in the definition of 530 components and composites. The attachment is specified by using the optional @policySets 531 attribute. This attribute takes as its value a list of policySet names. 532 For example, 533 534 service or reference. 535 binding.binding-type policySets=listOfQNames 536 /binding.binding-type. 537 /service or /reference ... Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org 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 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 - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
