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