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. > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > >
