Re: Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor

2008-03-20 Thread Venkata Krishnan
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 -

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";>


Used to indicate the transaction environment desired by
a component implementation.




Used to indicate that a component implementation requires a
managed global transaction.





Used to indicate that a component implementation requires a
managed local transaction.



..

---

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



Used to indicate that a component implementation requires a
managed global transaction.



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  get turned into a QName
> with ns = targetNamespace, localPart = anNCName
>
> - declarations of type  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 

Re: Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor

2008-03-20 Thread scabooz

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:

http://www.apache.org/tuscany"; ..>

   
   Used to indicate that a component implementation requires a
managed global transaction.
   
   


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" <[EMAIL PROTECTED]>

To: 
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 -

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";>

   
   Used to indicate the transaction environment desired 
by

a component implementation.
   

   
   
   Used to indicate that a component implementation requires a
managed global transaction.
   
   

   
   
   Used to indicate that a component implementation requires a
managed local transaction.
   
   

..

---

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


   
   Used to indicate that a component implementation requires a
managed global transaction.
   
   

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

>