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