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] > > > > >
