You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2008/03/19 21:44:56 UTC
Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor
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 <
> jsdelfino@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor
Posted by scabooz <sc...@gmail.com>.
Hi guys,
I'm not an XML expert but I think if you wanted that qualified intent
to be in a separate namespace you'd do it like this:
<definitions targetNamespace="http://www.apache.org/tuscany" ..>
<intent name="managedTransaction.global">
<description>
Used to indicate that a component implementation requires a
managed global transaction.
</description>
</intent>
</definitions>
You cannot put the QName into intent/@name.
I don't understand why anyone would want to put qualifiers in a
namespace different than the parent intent.
A recent decision in the OASIS Policy spec has made separate
namespaces impossible so I don't think you should spend much time
worrying about it.
Dave
----- Original Message -----
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Thursday, March 20, 2008 8:43 AM
Subject: Re: Qualifiable Policy intents - QNames or NCNames? was: About
StAXArtifactProcessor
> 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 <
> jsdelfino@apache.org> 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 <
>> > jsdelfino@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <
jsdelfino@apache.org> 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 <
> > jsdelfino@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>