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