I have fixed this under r634975. Thanks
- Venkat On Sat, Mar 8, 2008 at 3:33 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > Ok, I am going to fix this as follows : - > > - am keeping the name in the PolicyIntent and PolicySet model as QName and > assign for the namespaceURI, the targetNamespace specified for the > defintions.xml in question > - elsewhere in the definitions.xml where the intents defined here are > referenced, such as in Profile Intents or PolicySets, the intent names will > be used in qualified form with an appropriate prefix that points to the > targetnamespace. > > - Venkat > > > On Sat, Mar 8, 2008 at 3:40 AM, Greg Dritschler <[EMAIL PROTECTED]> > wrote: > > > See below. > > > > On Fri, Mar 7, 2008 at 12:11 PM, Venkata Krishnan <[EMAIL PROTECTED] > > > > > wrote: > > > > > 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. > > > > > > > Right. @requires takes a list of QNames so it can be composed of > > intents in > > various namespaces. I can see someone wanting to create a profile > > intent in > > their own namespace that uses intents in other standard namespaces. > > > > > > > > > > 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 ? > > > > > > > @provides is also a list of QNames so the usual rules for the prefix > > should > > be followed. If there is no prefix, then xmlns is used by default (not > > targetNamespace). If you want @provides to refer to an intent that's > > defined in the same definitions.xml, you need to define a namespace > > prefix > > for it (with the same value as targetNamespace) and use the prefix > > appropriately. > > > > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
