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