Hi Sebastien, Here is a snippet from https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy-transaction/src/main/resources/org/apache/tuscany/sca/policy/transaction/definitions.xml
----------------- definitions.xml --------------------- <definitions xmlns="http://www.osoa.org/xmlns/sca/1.0"; targetNamespace=" http://www.osoa.org/xmlns/sca/1.0"; xmlns:sca="http://www.osoa.org/xmlns/sca/1.0"; xmlns:tuscany=" http://tuscany.apache.org/xmlns/sca/1.0";> <intent name="managedTransaction" constrains="implementation"> <description>Used to indicate the transaction environment desired by a component implementation.</description> </intent> <intent name="managedTransaction.global"> <description> Used to indicate that a component implementation requires a managed global transaction. </description> </intent> <intent name="managedTransaction.local"> <description> Used to indicate that a component implementation requires a managed local transaction. </description> </intent> .............. ------------------------------------------------------------------------------------------- Over here, the intents "managedTransaction.global" and " managedTransaction.local" are qualified intents with "managedTransaction" being the qualifiable intent. Since we have decided that the 'name' attribute of an 'intent' element is going to be NCName we end up forcing the qualifiable intent to also belong to the targetnamespace. If it belonged to namespace other than the target, then we'd have to deal with how we can represent this for example we could resort to ... <intent name="tuscany:managedTransaction.global"> <description> Used to indicate that a component implementation requires a managed global transaction. </description> </intent> where we could say that managedTransaction is an intent defined under the namespace that the prefix 'tuscany' points to. But if we did this, the 'name' attribute must be read a QName which ends us in a contradiction. Thanks - Venkat On Thu, Mar 20, 2008 at 2:14 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > Venkata Krishnan wrote: > > Hi Sebastien, > > > > Thanks. Please find my comments inline. Not much though :) > > > > On Tue, Mar 18, 2008 at 3:46 AM, Jean-Sebastien Delfino < > > [EMAIL PROTECTED]> wrote: > > > >> Venkata Krishnan wrote: > >>>> 2) Unless I'm missing something, I don't think that you need to set > the > >>>> targetNamespace of QualifiedIntent.qualifiableIntents, as it looks > like > >>>> it's already read as a QName from the XML stream (and this QName does > >>>> not have to be in the current targetNamespace). > >>> > >>> First, I think that the Qualifiable intent needs to be in the current > >>> namespace since I I am not sure and the specs does not mention either, > >> on > >>> how we could represent a qualified intent whose qualifiable intent > >> belongs > >>> to a different namespace. So going with the assumption, in this > context > >> the > >>> qualifiable intent needs to be assigned the targetnamspace. Only then > >> would > >>> it be correctly resolved during the resolution phase. > >>> > >> Then I don't understand this code: > >> PolicyIntentProcessor:74 > >> qualifiableIntent.setName(getQNameValue(reader, > >> policyIntentName.substring(0, qualifierIndex))); > >> > >> which reads a QName from the XMLStreamReader. > >> > >> Either (a) the qualifiableIntent is always in the target namespace, and > >> then it's name is defined as an NCName and we shouldn't be trying to > >> read it as a QName, or (b) the qualifiable intent name is actually > >> defined as a QName and then it can belong to another namespace. > >> > >> If I understand it correctly, the policy-xsd defines these names as > >> QNames, leading me to believe that (b) is the correct option. > > > > > > Given the context of disussion in this thread (a) seems to be what it > should > > be. When cleaning up I missed out this line and I will fix it rightaway > > :(. But it ends up working because the name is reset with the > > targetnamespace later. Why I say (a) is because we'd then have > consistency > > with all intent names being NCNames. Ofcourse, this means that the > > qualifiable intents should also be from the same namespace. > > > > If we allowed intent names to be QNames then (b) would apply and we have > the > > freedom of having qualifiable intents belonging to a different namespace > > than the targetnamespace. But that will get us back to the bunch of > issues > > that has been discussed in > > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28653.html. > > > > I guess it can't be that qualified intents alone have names that are > QNames > > and the rest will be NCNames. > > > > Thanks > > > > - Venkat > > > > I'm still not sure I understand, I am assuming that when we read XML > declarations: > > - declarations of type <xyz name="anNCName"> get turned into a QName > with ns = targetNamespace, localPart = anNCName > > - declarations of type <xyz refToAnotherElement="QName"> just get the > QName as-is, and do not assume that it belongs to the document's > targetNamespace. > > But I'm probably missing something as it also seems to make sense to > restrict intent qualifiers to be in the same namespace as their > (qualifiable) parent intent. > > A concrete example would help, could you please post a definitions.xml > snippet example here containing a qualifiable intent and qualifiers to > help understand what makes more sense? an NCName or QName? > > Thanks! > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
