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