You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tuscany.apache.org by "ant elder (JIRA)" <tu...@ws.apache.org> on 2007/01/14 11:47:27 UTC

[jira] Created: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Use a Tuscany namespace for all non-spec'd Tuscany extensions
-------------------------------------------------------------

                 Key: TUSCANY-1053
                 URL: https://issues.apache.org/jira/browse/TUSCANY-1053
             Project: Tuscany
          Issue Type: Improvement
    Affects Versions: Java-M2
            Reporter: ant elder
            Priority: Minor
             Fix For: Java-M3


Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Simon Nash <na...@hursley.ibm.com>.

If I understand this comment correctly, this is a spec violation that
needs to be fixed.  From the assembly 1.0 spec:

2535 schemas. New interface types, implementation types and binding types that are defined using
2536 this extensibility model, which are not part of these SCA specifications must be defined in
2537 namespaces other than the SCA namespace.

   Simon

ant elder (JIRA) wrote:

>      [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> 
> ant elder closed TUSCANY-1053.
> ------------------------------
> 
>     Resolution: Fixed
> 
> Closing as it looks like we've standardized on using the SCA namespace
> 
> 
>>Use a Tuscany namespace for all non-spec'd Tuscany extensions
>>-------------------------------------------------------------
>>
>>                Key: TUSCANY-1053
>>                URL: https://issues.apache.org/jira/browse/TUSCANY-1053
>>            Project: Tuscany
>>         Issue Type: Improvement
>>         Components: Java SCA Assembly Model
>>   Affects Versions: Java-SCA-Next
>>           Reporter: ant elder
>>           Assignee: ant elder
>>            Fix For: Java-SCA-Next
>>
>>
>>Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Luciano Resende <lu...@gmail.com>.

Done under revision #568830

On 8/22/07, Mike Edwards <mi...@gmail.com> wrote:
> Jean-Sebastien,
>
> Jean-Sebastien Delfino wrote:
> <snip>
> >
> > Looks like option (B) is the most preferred option with:
> > - one -1
> > - five +1
> > - one "more spec compliant"
> >
> > Do we need more technical discussion? or a new [VOTE] thread to close
> > this issue?
> >
>
> Thanks for a great summary.
>
> I'm happy with the conclusion.
>
>
> Yours,  Mike.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Luciano Resende <lu...@gmail.com>.

Great summary Sebastien (you were faster then me), looks like option B
is the consensus, and I'd like to give it a try so we could still get
it to the release branch on the next couple days. Please let me know
if anyone has any objections.

On 8/21/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Simon Nash wrote:
> > -1 for A.  This violates the spec.
> > +1 for B.  Spec compliant, supports validation, and ensures
> > "future proof" SCDLs that won't break if Tuscany extension elements
> > are later adopted by the spec group but with subtle differences.
> > -1 for C alone.  -0.9 for C if done in addition to B.  C doesn't
> > handle the "future proofing" scenario, so the joy of simplicity will
> > turn into a nightmare if Tuscany extension elements are later adopted
> > by the spec group but with subtle differences.  I'm also not convinced
> > that simplicity is improved by providing two different alternatives here.
> >
> >   Simon
> >
> > Mike Edwards wrote:
> >
> >> Folks,
> >>
> >> In some ways, I'm glad I was on vacation while much of this debate
> >> raged!!   ;-)
> >>
> >> Comments below.....
> >>
> >> Jean-Sebastien Delfino wrote:
> >>
> >>> [A] What we have right now, standard SCA extensions and tuscany
> >>> extensions sharing the standard SCA namespace
> >>> (B) What IMO is a more correct use of XML namespaces, standard SCA
> >>> extensions in the standard SCA namespace, and Tuscany extensions in
> >>> a Tuscany namespace
> >>> [C] What an application developer could write if we allowed
> >>> namespaces to be omitted
> >>> ......
> >>> Now here are a few "side effects" :)
> >>>
> >>> Option [A]
> >>> - I cannot validate this composite against the standard SCA schemas
> >>> (it'll show errors in my XSD aware XML editor) our Tuscany
> >>> extensions violate the standard SCA namespace
> >>> - I have one less namespace and prefix declaration to care about
> >>>
> >>> Option [B]
> >>> - I can validate this composite against the standard SCA schemas, as
> >>> the Tuscany extensions match the xsd:any namespace="##other"
> >>> extensibility points in the SCA schema
> >>> - I have one more namespace and prefix declaration to write covering
> >>> the Tuscany extensions
> >>>
> >>> Option [C]
> >>> - I don't need to worry about namespaces, which are usually long and
> >>> error prone, writing the composite is simpler
> >>> - I cannot validate this composite against the standard SCA schemas
> >>> as it does not declare namespaces
> >>>
> >>> My preference is to do both:
> >>> - [B], be correct with respect to our usage of XML schema, to make
> >>> people who care about XML schema validation and use XML schema tools
> >>> happy
> >>> - and [C] allow people who don't like namespaces to not have to
> >>> write them
> >>>
> >>> Why do I like [C] as well? Here are a few examples:
> >>>
> >>> <html>
> >>>    <body>
> >>>       Hello! I can write XML without namespaces, isn't that nice?
> >>>    </body>
> >>> </html>
> >>>
> >>> An axis2.xml configuration file
> >>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml
> >>>
> >>>
> >>> An MS WCF configuration
> >>> http://msdn2.microsoft.com/en-us/library/ms735103.aspx
> >>>
> >>> A Tomcat server.xml file
> >>> http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html
> >>>
> >>> All work without namespaces...
> >>>
> >>
> >> Let me tackle them in reverse order (the more debateable first....)
> >>
> >> C) Yes, this is indeed simpler.  No namespaces is wonderful.  (PS I
> >> will  declare here that I am no fan of XML, so less XML always keeps
> >> me happy)
> >>
> >> The downside of this is that it "assumes" that you know all the valid
> >> XML in advance, if any validation is going to be done.  I suppose
> >> that you have options:
> >>
> >> - 1.  Don't worry about validation at all.
> >> - 2.  Do validation and have some non-namespace way of knowing all
> >> the     XSDs that contribute.
> >>
> >> The problem really hits when you start to build SCA Assemblies using
> >> tooling that is not part of Tuscany.  The SOA Tools project at
> >> Eclipse comes to mind.  We may come up with some approach for
> >> Tuscany, but can that also be used for the SOA Tools project?
> >>
> >> Namespaces may be ugly but at least they represent a standard that
> >> all can use....
> >>
> >> B) This is the SCA spec approach.  I'd recommend at least supporting
> >> this even if other techniques are also allowed.
> >>
> >> A) Is really problematic.  It implies hacking the XSDs defined by the
> >> SCA specs.  How will anyone know when they have violated the spec
> >> XSDs that form part of the Portability conformance that is part of
> >> the value of SCA (ie build and run my stuff on Tuscany and the same
> >> stuff should work on Oracle's runtime, if I stick to the stuff
> >> defined in the SCA specs...).
> >>
> >> A will also imply the existence of at least 2 sets of "SCA XSDs" -
> >> the spec ones and the Tuscany ones.  How will anyone know which one
> >> they've got in their hands....?
> >>
> >> So:
> >>
> >> A) -1    not a good place to be
> >> B) +1    its the standard
> >> C) +0.5  I can envisage this as +1 if it is an optional setting that
> >> a user can knowingly choose to use - as long as it is clear what they
> >> lose
> >>
> >>
> >> Yours,  Mike.
> >>
> >> PS The Microsoft WCF config works without a namespace since I think
> >> it is not extensible, unlike SCA which allows all kinds of extension.
> >>
> >> PS 2 If anyone can think of a better way for SCA to handle its
> >> extensibility, that will allow us to drop namespaces, the spec team
> >> will be all ears.  The spec group debated the use of namespaces at
> >> some length before adopting the current spec definition (and I was
> >> one of those trying to keep namespaces out of it....).
> >>
> >>
> >>
> >>
>
> No more technical comments on this thread today... So here's a summary
> of what people have said so far.
>
> - Ant:
>   A) +1
>   B) -1 on only doing B
>   C)
>
> - Luciano:
>   A)
>   B) more spec compliant
>   C)
>
> - Mike:
>   A) -1,
>   B) +1
>   C) +0.5 if we do B
>
> - Raymond:
>   A) -0.5
>   B) +1
>   C) -0.5
>
> - Sebastien:
>   A) +0.5
>   B) +1
>   C) proposed in addition to B
>
> - Simon:
>   A) -1
>   B) +1
>   C) -1 if alone, -0.9 if we do B
>
> - Venkat:
>   A)
>   B) +1
>   C)
>
> Looks like option (B) is the most preferred option with:
> - one -1
> - five +1
> - one "more spec compliant"
>
> Do we need more technical discussion? or a new [VOTE] thread to close
> this issue?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by ant elder <an...@gmail.com>.

Ok sure eventually why not. But I don't think we should wait till that
happens before doing [a].

   ...ant

On 8/20/07, Venkata Krishnan <fo...@gmail.com> wrote:
>
> Hi Ant, just to understand a little better - do you propose we must get
> our extensions endorsed by the Specs ?
>
> - Venkat
>
> On 8/20/07, ant elder < ant.elder@gmail.com> wrote:
> >
> > On 8/20/07, Jean-Sebastien Delfino < jsdelfino@apache.org> wrote:
> > >
> > > Luciano Resende wrote:
> > > > Sebastien wrote :
> > > >
> > > >> IMO application developers shouldn't have to suffer from the
> > > >>
> > > > complexity of XML...
> > > >
> > > >> How about supporting composites without namespace declarations at
> > all?
> > > >>
> > > >
> > > > I'm trying to understand all the proposals here, what would be the
> > > > side effects of going with your proposal ? This seems like simple,
> > and
> > > > simple is good...
> > > >
> > > >
> > > >
> > >
> > > Before getting into the side effects, here are three examples:
> > >
> > > [A] What we have right now, standard SCA extensions and tuscany
> > > extensions sharing the standard SCA namespace
> > >
> > > <composite xmlns=" http://www.osoa.org/xmlns/sca/1.0"
> > >     targetNamespace="http://bigbank"
> > >     xmlns:bb="http://bigbank"
> > >     name="BigBank">
> > >
> > >     <component name="AccountServiceComponent">
> > >         <service name="AccountService">
> > >             <binding.jsonrpc uri="/AccountJSONService"/>
> > >             <binding.ws
> > > wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)
> > <http://bigbank#wsdl.port%28AccountService/AccountServiceSoap%29>
> > > "/>
> > >             <binding.sca/>
> > >         </service>
> > >
> > >         <implementation.java class="bigbank.account.AccountServiceImpl
> > "/>
> > >
> > >         <reference name="accountDataService"
> > > target="AccountDataServiceComponent"/>
> > >         <reference name="calculatorService">
> > >             <binding.rmi host="localhost" port="8099"
> > > serviceName="CalculatorRMIService"/>
> > >            </reference>
> > >         <reference name="stockQuoteService">
> > >             <binding.ws
> > > wsdlElement="
> > > http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)<http://stockquote#wsdl.port%28StockQuoteService/StockQuoteSoapPort%29>
> > "/>
> > >         </reference>
> > >
> > >         <property name="currency">EURO</property>
> > >     </component>
> > >
> > >     <component name="AccountFeedComponent">
> > >            <service name="Collection">
> > >                <binding.rss uri="/rss"/>
> > >                < binding.atom uri="/atom"/>
> > >            </service>
> > >         <implementation.java class="
> > bigbank.account.feed.AccountFeedImpl
> > > "/>
> > >         <reference name="accountService"
> > > target="AccountServiceComponent"/>
> > >     </component>
> > >
> > >     <component name="AccountDataServiceComponent">
> > >         <implementation.composite name="bb:AccountData"/>
> > >     </component>
> > >
> > >     <component name="WebResourceComponent">
> > >            <service name="Resource">
> > >                <binding.resource uri="/"/>
> > >            </service>
> > >         <implementation.resource location="web"/>
> > >     </component>
> > >
> > > </composite>
> > >
> > >
> > > (B) What IMO is a more correct use of XML namespaces, standard SCA
> > > extensions in the standard SCA namespace, and Tuscany extensions in a
> > > Tuscany namespace
> > >
> > > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0 "
> > >     xmlns:t="http://incubator.apache.org/xmlns/tuscany/1.0"
> > >     targetNamespace="http://bigbank "
> > >     xmlns:bb="http://bigbank"
> > >     name="BigBank">
> > >
> > >     <component name="AccountServiceComponent">
> > >         <service name="AccountService">
> > >             <t:binding.jsonrpc uri="/AccountJSONService"/>
> > >             <binding.ws
> > > wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)<http://bigbank#wsdl.port%28AccountService/AccountServiceSoap%29>
> > > "/>
> > >             <binding.sca/>
> > >         </service>
> > >
> > >         <implementation.java class="bigbank.account.AccountServiceImpl"/>
> > >
> > >         <reference name="accountDataService"
> > > target="AccountDataServiceComponent"/>
> > >         <reference name="calculatorService">
> > >             <t: binding.rmi host="localhost" port="8099"
> > > serviceName="CalculatorRMIService"/>
> > >            </reference>
> > >         <reference name="stockQuoteService">
> > >             <binding.ws
> > > wsdlElement="
> > > http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)
> > <http://stockquote#wsdl.port%28StockQuoteService/StockQuoteSoapPort%29>
> > "/>
> > >         </reference>
> > >
> > >         <property name="currency">EURO</property>
> > >     </component>
> > >
> > >     <component name="AccountFeedComponent">
> > >            <service name="Collection">
> > >                <t:binding.rss uri="/rss"/>
> > >                <t:binding.atom uri="/atom"/>
> > >            </service>
> > >         <implementation.java class="
> > bigbank.account.feed.AccountFeedImpl
> > > "/>
> > >         <reference name="accountService"
> > > target="AccountServiceComponent"/>
> > >     </component>
> > >
> > >     <component name="AccountDataServiceComponent">
> > >         <implementation.composite name="bb:AccountData"/>
> > >     </component>
> > >
> > >     <component name="WebResourceComponent">
> > >            <service name="Resource">
> > >                <t:binding.resource uri="/"/>
> > >            </service>
> > >         <implementation.resource location="web"/>
> > >     </component>
> > >
> > > </composite>
> > >
> > > [C] What an application developer could write if we allowed namespaces
> >
> > > to be omitted
> > >
> > > <composite
> > >     name="BigBank">
> > >
> > >     <component name="AccountServiceComponent">
> > >         <service name="AccountService">
> > >             <binding.jsonrpc uri="/AccountJSONService"/>
> > >             <binding.ws
> > > wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)<http://bigbank#wsdl.port%28AccountService/AccountServiceSoap%29>
> > > "/>
> > >             <binding.sca/>
> > >         </service>
> > >
> > >         <implementation.java class="bigbank.account.AccountServiceImpl"/>
> > >
> > >         <reference name="accountDataService"
> > > target="AccountDataServiceComponent"/>
> > >         <reference name="calculatorService">
> > >             < binding.rmi host="localhost" port="8099"
> > > serviceName="CalculatorRMIService"/>
> > >            </reference>
> > >         <reference name="stockQuoteService">
> > >             <binding.ws
> > > wsdlElement="
> > > http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)
> > <http://stockquote#wsdl.port%28StockQuoteService/StockQuoteSoapPort%29>
> > "/>
> > >         </reference>
> > >
> > >         <property name="currency">EURO</property>
> > >     </component>
> > >
> > >     <component name="AccountFeedComponent">
> > >            <service name="Collection">
> > >                <binding.rss uri="/rss"/>
> > >                <binding.atom uri="/atom"/>
> > >            </service>
> > >         <implementation.java class="
> > bigbank.account.feed.AccountFeedImpl
> > > "/>
> > >         <reference name="accountService"
> > > target="AccountServiceComponent"/>
> > >     </component>
> > >
> > >     <component name="AccountDataServiceComponent">
> > >         <implementation.composite name="AccountData"/>
> > >     </component>
> > >
> > >     <component name="WebResourceComponent">
> > >            <service name="Resource">
> > >                <binding.resource uri="/"/>
> > >            </service>
> > >         <implementation.resource location="web"/>
> > >     </component>
> > >
> > > </composite>
> > >
> > > Now here are a few "side effects" :)
> > >
> > > Option [A]
> > > - I cannot validate this composite against the standard SCA schemas
> > > (it'll show errors in my XSD aware XML editor) our Tuscany extensions
> > > violate the standard SCA namespace
> > > - I have one less namespace and prefix declaration to care about
> > >
> > > Option [B]
> > > - I can validate this composite against the standard SCA schemas, as
> > the
> > > Tuscany extensions match the xsd:any namespace="##other" extensibility
> > > points in the SCA schema
> > > - I have one more namespace and prefix declaration to write covering
> > the
> > > Tuscany extensions
> > >
> > > Option [C]
> > > - I don't need to worry about namespaces, which are usually long and
> > > error prone, writing the composite is simpler
> > > - I cannot validate this composite against the standard SCA schemas as
> > > it does not declare namespaces
> > >
> > > My preference is to do both:
> > > - [B], be correct with respect to our usage of XML schema, to make
> > > people who care about XML schema validation and use XML schema tools
> > happy
> > > - and [C] allow people who don't like namespaces to not have to write
> > them
> > >
> > > Why do I like [C] as well? Here are a few examples:
> > >
> > > <html>
> > >     <body>
> > >        Hello! I can write XML without namespaces, isn't that nice?
> > >     </body>
> > > </html>
> > >
> > > An axis2.xml configuration file
> > >
> > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml
> >
> > >
> > > An MS WCF configuration
> > > http://msdn2.microsoft.com/en-us/library/ms735103.aspx
> > >
> > > A Tomcat server.xml file
> > > http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html
> > >
> > > All work without namespaces...
> >
> >
> > I'm still +1 on [a]. Couldn't we fix the problem with validation by just
> >
> > creating proper schema's for the Tuscany extensions as if they were
> > defined
> > in specs?
> >
> > -1 on only doing [b]. Everyone always moans about XML configuration,
> > most
> > other projects spend a lot of time finding ways to simplify their config
> > XML
> > and make things easier for users and here we are setting out to make
> > ours
> > significantly more complicated and ugly. Seems like shooting ourselves
> > in
> > the foot to me.
> >
> > I'm not sure about [c] yet, not being able to do scheme validation isn't
> >
> > great, would we change all the samples and tests to use the no namespace
> > way?
> >
> >    ...ant
> >
>
>

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Venkata Krishnan <fo...@gmail.com>.

Hi Ant, just to understand a little better - do you propose we must get our
extensions endorsed by the Specs ?

- Venkat

On 8/20/07, ant elder <an...@gmail.com> wrote:
>
> On 8/20/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > Luciano Resende wrote:
> > > Sebastien wrote :
> > >
> > >> IMO application developers shouldn't have to suffer from the
> > >>
> > > complexity of XML...
> > >
> > >> How about supporting composites without namespace declarations at
> all?
> > >>
> > >
> > > I'm trying to understand all the proposals here, what would be the
> > > side effects of going with your proposal ? This seems like simple, and
> > > simple is good...
> > >
> > >
> > >
> >
> > Before getting into the side effects, here are three examples:
> >
> > [A] What we have right now, standard SCA extensions and tuscany
> > extensions sharing the standard SCA namespace
> >
> > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> >     targetNamespace="http://bigbank"
> >     xmlns:bb="http://bigbank"
> >     name="BigBank">
> >
> >     <component name="AccountServiceComponent">
> >         <service name="AccountService">
> >             <binding.jsonrpc uri="/AccountJSONService"/>
> >             <binding.ws
> > wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)
> > "/>
> >             <binding.sca/>
> >         </service>
> >
> >         <implementation.java class="bigbank.account.AccountServiceImpl
> "/>
> >
> >         <reference name="accountDataService"
> > target="AccountDataServiceComponent"/>
> >         <reference name="calculatorService">
> >             <binding.rmi host="localhost" port="8099"
> > serviceName="CalculatorRMIService"/>
> >            </reference>
> >         <reference name="stockQuoteService">
> >             <binding.ws
> > wsdlElement="
> > http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
> >         </reference>
> >
> >         <property name="currency">EURO</property>
> >     </component>
> >
> >     <component name="AccountFeedComponent">
> >            <service name="Collection">
> >                <binding.rss uri="/rss"/>
> >                <binding.atom uri="/atom"/>
> >            </service>
> >         <implementation.java class="bigbank.account.feed.AccountFeedImpl
> > "/>
> >         <reference name="accountService"
> > target="AccountServiceComponent"/>
> >     </component>
> >
> >     <component name="AccountDataServiceComponent">
> >         <implementation.composite name="bb:AccountData"/>
> >     </component>
> >
> >     <component name="WebResourceComponent">
> >            <service name="Resource">
> >                <binding.resource uri="/"/>
> >            </service>
> >         <implementation.resource location="web"/>
> >     </component>
> >
> > </composite>
> >
> >
> > (B) What IMO is a more correct use of XML namespaces, standard SCA
> > extensions in the standard SCA namespace, and Tuscany extensions in a
> > Tuscany namespace
> >
> > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> >     xmlns:t="http://incubator.apache.org/xmlns/tuscany/1.0"
> >     targetNamespace="http://bigbank"
> >     xmlns:bb="http://bigbank"
> >     name="BigBank">
> >
> >     <component name="AccountServiceComponent">
> >         <service name="AccountService">
> >             <t:binding.jsonrpc uri="/AccountJSONService"/>
> >             <binding.ws
> > wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)
> > "/>
> >             <binding.sca/>
> >         </service>
> >
> >         <implementation.java class="bigbank.account.AccountServiceImpl
> "/>
> >
> >         <reference name="accountDataService"
> > target="AccountDataServiceComponent"/>
> >         <reference name="calculatorService">
> >             <t:binding.rmi host="localhost" port="8099"
> > serviceName="CalculatorRMIService"/>
> >            </reference>
> >         <reference name="stockQuoteService">
> >             <binding.ws
> > wsdlElement="
> > http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
> >         </reference>
> >
> >         <property name="currency">EURO</property>
> >     </component>
> >
> >     <component name="AccountFeedComponent">
> >            <service name="Collection">
> >                <t:binding.rss uri="/rss"/>
> >                <t:binding.atom uri="/atom"/>
> >            </service>
> >         <implementation.java class="bigbank.account.feed.AccountFeedImpl
> > "/>
> >         <reference name="accountService"
> > target="AccountServiceComponent"/>
> >     </component>
> >
> >     <component name="AccountDataServiceComponent">
> >         <implementation.composite name="bb:AccountData"/>
> >     </component>
> >
> >     <component name="WebResourceComponent">
> >            <service name="Resource">
> >                <t:binding.resource uri="/"/>
> >            </service>
> >         <implementation.resource location="web"/>
> >     </component>
> >
> > </composite>
> >
> > [C] What an application developer could write if we allowed namespaces
> > to be omitted
> >
> > <composite
> >     name="BigBank">
> >
> >     <component name="AccountServiceComponent">
> >         <service name="AccountService">
> >             <binding.jsonrpc uri="/AccountJSONService"/>
> >             <binding.ws
> > wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)
> > "/>
> >             <binding.sca/>
> >         </service>
> >
> >         <implementation.java class="bigbank.account.AccountServiceImpl
> "/>
> >
> >         <reference name="accountDataService"
> > target="AccountDataServiceComponent"/>
> >         <reference name="calculatorService">
> >             <binding.rmi host="localhost" port="8099"
> > serviceName="CalculatorRMIService"/>
> >            </reference>
> >         <reference name="stockQuoteService">
> >             <binding.ws
> > wsdlElement="
> > http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
> >         </reference>
> >
> >         <property name="currency">EURO</property>
> >     </component>
> >
> >     <component name="AccountFeedComponent">
> >            <service name="Collection">
> >                <binding.rss uri="/rss"/>
> >                <binding.atom uri="/atom"/>
> >            </service>
> >         <implementation.java class="bigbank.account.feed.AccountFeedImpl
> > "/>
> >         <reference name="accountService"
> > target="AccountServiceComponent"/>
> >     </component>
> >
> >     <component name="AccountDataServiceComponent">
> >         <implementation.composite name="AccountData"/>
> >     </component>
> >
> >     <component name="WebResourceComponent">
> >            <service name="Resource">
> >                <binding.resource uri="/"/>
> >            </service>
> >         <implementation.resource location="web"/>
> >     </component>
> >
> > </composite>
> >
> > Now here are a few "side effects" :)
> >
> > Option [A]
> > - I cannot validate this composite against the standard SCA schemas
> > (it'll show errors in my XSD aware XML editor) our Tuscany extensions
> > violate the standard SCA namespace
> > - I have one less namespace and prefix declaration to care about
> >
> > Option [B]
> > - I can validate this composite against the standard SCA schemas, as the
> > Tuscany extensions match the xsd:any namespace="##other" extensibility
> > points in the SCA schema
> > - I have one more namespace and prefix declaration to write covering the
> > Tuscany extensions
> >
> > Option [C]
> > - I don't need to worry about namespaces, which are usually long and
> > error prone, writing the composite is simpler
> > - I cannot validate this composite against the standard SCA schemas as
> > it does not declare namespaces
> >
> > My preference is to do both:
> > - [B], be correct with respect to our usage of XML schema, to make
> > people who care about XML schema validation and use XML schema tools
> happy
> > - and [C] allow people who don't like namespaces to not have to write
> them
> >
> > Why do I like [C] as well? Here are a few examples:
> >
> > <html>
> >     <body>
> >        Hello! I can write XML without namespaces, isn't that nice?
> >     </body>
> > </html>
> >
> > An axis2.xml configuration file
> >
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml
> >
> > An MS WCF configuration
> > http://msdn2.microsoft.com/en-us/library/ms735103.aspx
> >
> > A Tomcat server.xml file
> > http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html
> >
> > All work without namespaces...
>
>
> I'm still +1 on [a]. Couldn't we fix the problem with validation by just
> creating proper schema's for the Tuscany extensions as if they were
> defined
> in specs?
>
> -1 on only doing [b]. Everyone always moans about XML configuration, most
> other projects spend a lot of time finding ways to simplify their config
> XML
> and make things easier for users and here we are setting out to make ours
> significantly more complicated and ugly. Seems like shooting ourselves in
> the foot to me.
>
> I'm not sure about [c] yet, not being able to do scheme validation isn't
> great, would we change all the samples and tests to use the no namespace
> way?
>
>    ...ant
>

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by ant elder <an...@gmail.com>.

On 8/20/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Luciano Resende wrote:
> > Sebastien wrote :
> >
> >> IMO application developers shouldn't have to suffer from the
> >>
> > complexity of XML...
> >
> >> How about supporting composites without namespace declarations at all?
> >>
> >
> > I'm trying to understand all the proposals here, what would be the
> > side effects of going with your proposal ? This seems like simple, and
> > simple is good...
> >
> >
> >
>
> Before getting into the side effects, here are three examples:
>
> [A] What we have right now, standard SCA extensions and tuscany
> extensions sharing the standard SCA namespace
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>     targetNamespace="http://bigbank"
>     xmlns:bb="http://bigbank"
>     name="BigBank">
>
>     <component name="AccountServiceComponent">
>         <service name="AccountService">
>             <binding.jsonrpc uri="/AccountJSONService"/>
>             <binding.ws
> wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)
> "/>
>             <binding.sca/>
>         </service>
>
>         <implementation.java class="bigbank.account.AccountServiceImpl"/>
>
>         <reference name="accountDataService"
> target="AccountDataServiceComponent"/>
>         <reference name="calculatorService">
>             <binding.rmi host="localhost" port="8099"
> serviceName="CalculatorRMIService"/>
>            </reference>
>         <reference name="stockQuoteService">
>             <binding.ws
> wsdlElement="
> http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
>         </reference>
>
>         <property name="currency">EURO</property>
>     </component>
>
>     <component name="AccountFeedComponent">
>            <service name="Collection">
>                <binding.rss uri="/rss"/>
>                <binding.atom uri="/atom"/>
>            </service>
>         <implementation.java class="bigbank.account.feed.AccountFeedImpl
> "/>
>         <reference name="accountService"
> target="AccountServiceComponent"/>
>     </component>
>
>     <component name="AccountDataServiceComponent">
>         <implementation.composite name="bb:AccountData"/>
>     </component>
>
>     <component name="WebResourceComponent">
>            <service name="Resource">
>                <binding.resource uri="/"/>
>            </service>
>         <implementation.resource location="web"/>
>     </component>
>
> </composite>
>
>
> (B) What IMO is a more correct use of XML namespaces, standard SCA
> extensions in the standard SCA namespace, and Tuscany extensions in a
> Tuscany namespace
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>     xmlns:t="http://incubator.apache.org/xmlns/tuscany/1.0"
>     targetNamespace="http://bigbank"
>     xmlns:bb="http://bigbank"
>     name="BigBank">
>
>     <component name="AccountServiceComponent">
>         <service name="AccountService">
>             <t:binding.jsonrpc uri="/AccountJSONService"/>
>             <binding.ws
> wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)
> "/>
>             <binding.sca/>
>         </service>
>
>         <implementation.java class="bigbank.account.AccountServiceImpl"/>
>
>         <reference name="accountDataService"
> target="AccountDataServiceComponent"/>
>         <reference name="calculatorService">
>             <t:binding.rmi host="localhost" port="8099"
> serviceName="CalculatorRMIService"/>
>            </reference>
>         <reference name="stockQuoteService">
>             <binding.ws
> wsdlElement="
> http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
>         </reference>
>
>         <property name="currency">EURO</property>
>     </component>
>
>     <component name="AccountFeedComponent">
>            <service name="Collection">
>                <t:binding.rss uri="/rss"/>
>                <t:binding.atom uri="/atom"/>
>            </service>
>         <implementation.java class="bigbank.account.feed.AccountFeedImpl
> "/>
>         <reference name="accountService"
> target="AccountServiceComponent"/>
>     </component>
>
>     <component name="AccountDataServiceComponent">
>         <implementation.composite name="bb:AccountData"/>
>     </component>
>
>     <component name="WebResourceComponent">
>            <service name="Resource">
>                <t:binding.resource uri="/"/>
>            </service>
>         <implementation.resource location="web"/>
>     </component>
>
> </composite>
>
> [C] What an application developer could write if we allowed namespaces
> to be omitted
>
> <composite
>     name="BigBank">
>
>     <component name="AccountServiceComponent">
>         <service name="AccountService">
>             <binding.jsonrpc uri="/AccountJSONService"/>
>             <binding.ws
> wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)
> "/>
>             <binding.sca/>
>         </service>
>
>         <implementation.java class="bigbank.account.AccountServiceImpl"/>
>
>         <reference name="accountDataService"
> target="AccountDataServiceComponent"/>
>         <reference name="calculatorService">
>             <binding.rmi host="localhost" port="8099"
> serviceName="CalculatorRMIService"/>
>            </reference>
>         <reference name="stockQuoteService">
>             <binding.ws
> wsdlElement="
> http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
>         </reference>
>
>         <property name="currency">EURO</property>
>     </component>
>
>     <component name="AccountFeedComponent">
>            <service name="Collection">
>                <binding.rss uri="/rss"/>
>                <binding.atom uri="/atom"/>
>            </service>
>         <implementation.java class="bigbank.account.feed.AccountFeedImpl
> "/>
>         <reference name="accountService"
> target="AccountServiceComponent"/>
>     </component>
>
>     <component name="AccountDataServiceComponent">
>         <implementation.composite name="AccountData"/>
>     </component>
>
>     <component name="WebResourceComponent">
>            <service name="Resource">
>                <binding.resource uri="/"/>
>            </service>
>         <implementation.resource location="web"/>
>     </component>
>
> </composite>
>
> Now here are a few "side effects" :)
>
> Option [A]
> - I cannot validate this composite against the standard SCA schemas
> (it'll show errors in my XSD aware XML editor) our Tuscany extensions
> violate the standard SCA namespace
> - I have one less namespace and prefix declaration to care about
>
> Option [B]
> - I can validate this composite against the standard SCA schemas, as the
> Tuscany extensions match the xsd:any namespace="##other" extensibility
> points in the SCA schema
> - I have one more namespace and prefix declaration to write covering the
> Tuscany extensions
>
> Option [C]
> - I don't need to worry about namespaces, which are usually long and
> error prone, writing the composite is simpler
> - I cannot validate this composite against the standard SCA schemas as
> it does not declare namespaces
>
> My preference is to do both:
> - [B], be correct with respect to our usage of XML schema, to make
> people who care about XML schema validation and use XML schema tools happy
> - and [C] allow people who don't like namespaces to not have to write them
>
> Why do I like [C] as well? Here are a few examples:
>
> <html>
>     <body>
>        Hello! I can write XML without namespaces, isn't that nice?
>     </body>
> </html>
>
> An axis2.xml configuration file
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml
>
> An MS WCF configuration
> http://msdn2.microsoft.com/en-us/library/ms735103.aspx
>
> A Tomcat server.xml file
> http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html
>
> All work without namespaces...


I'm still +1 on [a]. Couldn't we fix the problem with validation by just
creating proper schema's for the Tuscany extensions as if they were defined
in specs?

-1 on only doing [b]. Everyone always moans about XML configuration, most
other projects spend a lot of time finding ways to simplify their config XML
and make things easier for users and here we are setting out to make ours
significantly more complicated and ugly. Seems like shooting ourselves in
the foot to me.

I'm not sure about [c] yet, not being able to do scheme validation isn't
great, would we change all the samples and tests to use the no namespace
way?

   ...ant

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Venkata Krishnan <fo...@gmail.com>.

+1 for option [B] alone.  Given the fact that we are going to rely more on
tooling to define composites this shouldn't be a problem.

- Venkat

On 8/20/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Luciano Resende wrote:
> > Sebastien wrote :
> >
> >> IMO application developers shouldn't have to suffer from the
> >>
> > complexity of XML...
> >
> >> How about supporting composites without namespace declarations at all?
> >>
> >
> > I'm trying to understand all the proposals here, what would be the
> > side effects of going with your proposal ? This seems like simple, and
> > simple is good...
> >
> >
> >
>
> Before getting into the side effects, here are three examples:
>
> [A] What we have right now, standard SCA extensions and tuscany
> extensions sharing the standard SCA namespace
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>     targetNamespace="http://bigbank"
>     xmlns:bb="http://bigbank"
>     name="BigBank">
>
>     <component name="AccountServiceComponent">
>         <service name="AccountService">
>             <binding.jsonrpc uri="/AccountJSONService"/>
>             <binding.ws
> wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)
> "/>
>             <binding.sca/>
>         </service>
>
>         <implementation.java class="bigbank.account.AccountServiceImpl"/>
>
>         <reference name="accountDataService"
> target="AccountDataServiceComponent"/>
>         <reference name="calculatorService">
>             <binding.rmi host="localhost" port="8099"
> serviceName="CalculatorRMIService"/>
>            </reference>
>         <reference name="stockQuoteService">
>             <binding.ws
> wsdlElement="
> http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
>         </reference>
>
>         <property name="currency">EURO</property>
>     </component>
>
>     <component name="AccountFeedComponent">
>            <service name="Collection">
>                <binding.rss uri="/rss"/>
>                <binding.atom uri="/atom"/>
>            </service>
>         <implementation.java class="bigbank.account.feed.AccountFeedImpl
> "/>
>         <reference name="accountService"
> target="AccountServiceComponent"/>
>     </component>
>
>     <component name="AccountDataServiceComponent">
>         <implementation.composite name="bb:AccountData"/>
>     </component>
>
>     <component name="WebResourceComponent">
>            <service name="Resource">
>                <binding.resource uri="/"/>
>            </service>
>         <implementation.resource location="web"/>
>     </component>
>
> </composite>
>
>
> (B) What IMO is a more correct use of XML namespaces, standard SCA
> extensions in the standard SCA namespace, and Tuscany extensions in a
> Tuscany namespace
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>     xmlns:t="http://incubator.apache.org/xmlns/tuscany/1.0"
>     targetNamespace="http://bigbank"
>     xmlns:bb="http://bigbank"
>     name="BigBank">
>
>     <component name="AccountServiceComponent">
>         <service name="AccountService">
>             <t:binding.jsonrpc uri="/AccountJSONService"/>
>             <binding.ws
> wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)
> "/>
>             <binding.sca/>
>         </service>
>
>         <implementation.java class="bigbank.account.AccountServiceImpl"/>
>
>         <reference name="accountDataService"
> target="AccountDataServiceComponent"/>
>         <reference name="calculatorService">
>             <t:binding.rmi host="localhost" port="8099"
> serviceName="CalculatorRMIService"/>
>            </reference>
>         <reference name="stockQuoteService">
>             <binding.ws
> wsdlElement="
> http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
>         </reference>
>
>         <property name="currency">EURO</property>
>     </component>
>
>     <component name="AccountFeedComponent">
>            <service name="Collection">
>                <t:binding.rss uri="/rss"/>
>                <t:binding.atom uri="/atom"/>
>            </service>
>         <implementation.java class="bigbank.account.feed.AccountFeedImpl
> "/>
>         <reference name="accountService"
> target="AccountServiceComponent"/>
>     </component>
>
>     <component name="AccountDataServiceComponent">
>         <implementation.composite name="bb:AccountData"/>
>     </component>
>
>     <component name="WebResourceComponent">
>            <service name="Resource">
>                <t:binding.resource uri="/"/>
>            </service>
>         <implementation.resource location="web"/>
>     </component>
>
> </composite>
>
> [C] What an application developer could write if we allowed namespaces
> to be omitted
>
> <composite
>     name="BigBank">
>
>     <component name="AccountServiceComponent">
>         <service name="AccountService">
>             <binding.jsonrpc uri="/AccountJSONService"/>
>             <binding.ws
> wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)
> "/>
>             <binding.sca/>
>         </service>
>
>         <implementation.java class="bigbank.account.AccountServiceImpl"/>
>
>         <reference name="accountDataService"
> target="AccountDataServiceComponent"/>
>         <reference name="calculatorService">
>             <binding.rmi host="localhost" port="8099"
> serviceName="CalculatorRMIService"/>
>            </reference>
>         <reference name="stockQuoteService">
>             <binding.ws
> wsdlElement="
> http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
>         </reference>
>
>         <property name="currency">EURO</property>
>     </component>
>
>     <component name="AccountFeedComponent">
>            <service name="Collection">
>                <binding.rss uri="/rss"/>
>                <binding.atom uri="/atom"/>
>            </service>
>         <implementation.java class="bigbank.account.feed.AccountFeedImpl
> "/>
>         <reference name="accountService"
> target="AccountServiceComponent"/>
>     </component>
>
>     <component name="AccountDataServiceComponent">
>         <implementation.composite name="AccountData"/>
>     </component>
>
>     <component name="WebResourceComponent">
>            <service name="Resource">
>                <binding.resource uri="/"/>
>            </service>
>         <implementation.resource location="web"/>
>     </component>
>
> </composite>
>
> Now here are a few "side effects" :)
>
> Option [A]
> - I cannot validate this composite against the standard SCA schemas
> (it'll show errors in my XSD aware XML editor) our Tuscany extensions
> violate the standard SCA namespace
> - I have one less namespace and prefix declaration to care about
>
> Option [B]
> - I can validate this composite against the standard SCA schemas, as the
> Tuscany extensions match the xsd:any namespace="##other" extensibility
> points in the SCA schema
> - I have one more namespace and prefix declaration to write covering the
> Tuscany extensions
>
> Option [C]
> - I don't need to worry about namespaces, which are usually long and
> error prone, writing the composite is simpler
> - I cannot validate this composite against the standard SCA schemas as
> it does not declare namespaces
>
> My preference is to do both:
> - [B], be correct with respect to our usage of XML schema, to make
> people who care about XML schema validation and use XML schema tools happy
> - and [C] allow people who don't like namespaces to not have to write them
>
> Why do I like [C] as well? Here are a few examples:
>
> <html>
>     <body>
>        Hello! I can write XML without namespaces, isn't that nice?
>     </body>
> </html>
>
> An axis2.xml configuration file
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml
>
> An MS WCF configuration
> http://msdn2.microsoft.com/en-us/library/ms735103.aspx
>
> A Tomcat server.xml file
> http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html
>
> All work without namespaces...
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Mike Edwards <mi...@gmail.com>.

Jean-Sebastien,

Jean-Sebastien Delfino wrote:
<snip>
> 
> Looks like option (B) is the most preferred option with:
> - one -1
> - five +1
> - one "more spec compliant"
> 
> Do we need more technical discussion? or a new [VOTE] thread to close 
> this issue?
> 

Thanks for a great summary.

I'm happy with the conclusion.


Yours,  Mike.

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jean-Sebastien Delfino <js...@apache.org>.

Simon Nash wrote:
> -1 for A.  This violates the spec.
> +1 for B.  Spec compliant, supports validation, and ensures
> "future proof" SCDLs that won't break if Tuscany extension elements
> are later adopted by the spec group but with subtle differences.
> -1 for C alone.  -0.9 for C if done in addition to B.  C doesn't
> handle the "future proofing" scenario, so the joy of simplicity will
> turn into a nightmare if Tuscany extension elements are later adopted
> by the spec group but with subtle differences.  I'm also not convinced
> that simplicity is improved by providing two different alternatives here.
>
>   Simon
>
> Mike Edwards wrote:
>
>> Folks,
>>
>> In some ways, I'm glad I was on vacation while much of this debate 
>> raged!!   ;-)
>>
>> Comments below.....
>>
>> Jean-Sebastien Delfino wrote:
>>
>>> [A] What we have right now, standard SCA extensions and tuscany 
>>> extensions sharing the standard SCA namespace
>>> (B) What IMO is a more correct use of XML namespaces, standard SCA 
>>> extensions in the standard SCA namespace, and Tuscany extensions in 
>>> a Tuscany namespace
>>> [C] What an application developer could write if we allowed 
>>> namespaces to be omitted
>>> ......
>>> Now here are a few "side effects" :)
>>>
>>> Option [A]
>>> - I cannot validate this composite against the standard SCA schemas 
>>> (it'll show errors in my XSD aware XML editor) our Tuscany 
>>> extensions violate the standard SCA namespace
>>> - I have one less namespace and prefix declaration to care about
>>>
>>> Option [B]
>>> - I can validate this composite against the standard SCA schemas, as 
>>> the Tuscany extensions match the xsd:any namespace="##other" 
>>> extensibility points in the SCA schema
>>> - I have one more namespace and prefix declaration to write covering 
>>> the Tuscany extensions
>>>
>>> Option [C]
>>> - I don't need to worry about namespaces, which are usually long and 
>>> error prone, writing the composite is simpler
>>> - I cannot validate this composite against the standard SCA schemas 
>>> as it does not declare namespaces
>>>
>>> My preference is to do both:
>>> - [B], be correct with respect to our usage of XML schema, to make 
>>> people who care about XML schema validation and use XML schema tools 
>>> happy
>>> - and [C] allow people who don't like namespaces to not have to 
>>> write them
>>>
>>> Why do I like [C] as well? Here are a few examples:
>>>
>>> <html>
>>>    <body>
>>>       Hello! I can write XML without namespaces, isn't that nice?
>>>    </body>
>>> </html>
>>>
>>> An axis2.xml configuration file
>>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml 
>>>
>>>
>>> An MS WCF configuration
>>> http://msdn2.microsoft.com/en-us/library/ms735103.aspx
>>>
>>> A Tomcat server.xml file
>>> http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html
>>>
>>> All work without namespaces...
>>>
>>
>> Let me tackle them in reverse order (the more debateable first....)
>>
>> C) Yes, this is indeed simpler.  No namespaces is wonderful.  (PS I 
>> will  declare here that I am no fan of XML, so less XML always keeps 
>> me happy)
>>
>> The downside of this is that it "assumes" that you know all the valid 
>> XML in advance, if any validation is going to be done.  I suppose 
>> that you have options:
>>
>> - 1.  Don't worry about validation at all.
>> - 2.  Do validation and have some non-namespace way of knowing all 
>> the     XSDs that contribute.
>>
>> The problem really hits when you start to build SCA Assemblies using 
>> tooling that is not part of Tuscany.  The SOA Tools project at 
>> Eclipse comes to mind.  We may come up with some approach for 
>> Tuscany, but can that also be used for the SOA Tools project?
>>
>> Namespaces may be ugly but at least they represent a standard that 
>> all can use....
>>
>> B) This is the SCA spec approach.  I'd recommend at least supporting 
>> this even if other techniques are also allowed.
>>
>> A) Is really problematic.  It implies hacking the XSDs defined by the 
>> SCA specs.  How will anyone know when they have violated the spec 
>> XSDs that form part of the Portability conformance that is part of 
>> the value of SCA (ie build and run my stuff on Tuscany and the same 
>> stuff should work on Oracle's runtime, if I stick to the stuff 
>> defined in the SCA specs...).
>>
>> A will also imply the existence of at least 2 sets of "SCA XSDs" - 
>> the spec ones and the Tuscany ones.  How will anyone know which one 
>> they've got in their hands....?
>>
>> So:
>>
>> A) -1    not a good place to be
>> B) +1    its the standard
>> C) +0.5  I can envisage this as +1 if it is an optional setting that 
>> a user can knowingly choose to use - as long as it is clear what they 
>> lose
>>
>>
>> Yours,  Mike.
>>
>> PS The Microsoft WCF config works without a namespace since I think 
>> it is not extensible, unlike SCA which allows all kinds of extension.
>>
>> PS 2 If anyone can think of a better way for SCA to handle its 
>> extensibility, that will allow us to drop namespaces, the spec team 
>> will be all ears.  The spec group debated the use of namespaces at 
>> some length before adopting the current spec definition (and I was 
>> one of those trying to keep namespaces out of it....).
>>
>>
>>
>>

No more technical comments on this thread today... So here's a summary 
of what people have said so far.

- Ant:
  A) +1
  B) -1 on only doing B
  C)

- Luciano:
  A)
  B) more spec compliant
  C)

- Mike:
  A) -1,
  B) +1
  C) +0.5 if we do B

- Raymond:
  A) -0.5
  B) +1
  C) -0.5

- Sebastien:
  A) +0.5
  B) +1
  C) proposed in addition to B

- Simon:
  A) -1
  B) +1
  C) -1 if alone, -0.9 if we do B

- Venkat:
  A)
  B) +1
  C)

Looks like option (B) is the most preferred option with:
- one -1
- five +1
- one "more spec compliant"

Do we need more technical discussion? or a new [VOTE] thread to close 
this issue?

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Simon Nash <na...@hursley.ibm.com>.

-1 for A.  This violates the spec.
+1 for B.  Spec compliant, supports validation, and ensures
"future proof" SCDLs that won't break if Tuscany extension elements
are later adopted by the spec group but with subtle differences.
-1 for C alone.  -0.9 for C if done in addition to B.  C doesn't
handle the "future proofing" scenario, so the joy of simplicity will
turn into a nightmare if Tuscany extension elements are later adopted
by the spec group but with subtle differences.  I'm also not convinced
that simplicity is improved by providing two different alternatives here.

   Simon

Mike Edwards wrote:

> Folks,
> 
> In some ways, I'm glad I was on vacation while much of this debate 
> raged!!   ;-)
> 
> Comments below.....
> 
> Jean-Sebastien Delfino wrote:
> 
>> [A] What we have right now, standard SCA extensions and tuscany 
>> extensions sharing the standard SCA namespace
>> (B) What IMO is a more correct use of XML namespaces, standard SCA 
>> extensions in the standard SCA namespace, and Tuscany extensions in a 
>> Tuscany namespace
>> [C] What an application developer could write if we allowed namespaces 
>> to be omitted
>> ......
>> Now here are a few "side effects" :)
>>
>> Option [A]
>> - I cannot validate this composite against the standard SCA schemas 
>> (it'll show errors in my XSD aware XML editor) our Tuscany extensions 
>> violate the standard SCA namespace
>> - I have one less namespace and prefix declaration to care about
>>
>> Option [B]
>> - I can validate this composite against the standard SCA schemas, as 
>> the Tuscany extensions match the xsd:any namespace="##other" 
>> extensibility points in the SCA schema
>> - I have one more namespace and prefix declaration to write covering 
>> the Tuscany extensions
>>
>> Option [C]
>> - I don't need to worry about namespaces, which are usually long and 
>> error prone, writing the composite is simpler
>> - I cannot validate this composite against the standard SCA schemas as 
>> it does not declare namespaces
>>
>> My preference is to do both:
>> - [B], be correct with respect to our usage of XML schema, to make 
>> people who care about XML schema validation and use XML schema tools 
>> happy
>> - and [C] allow people who don't like namespaces to not have to write 
>> them
>>
>> Why do I like [C] as well? Here are a few examples:
>>
>> <html>
>>    <body>
>>       Hello! I can write XML without namespaces, isn't that nice?
>>    </body>
>> </html>
>>
>> An axis2.xml configuration file
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml 
>>
>>
>> An MS WCF configuration
>> http://msdn2.microsoft.com/en-us/library/ms735103.aspx
>>
>> A Tomcat server.xml file
>> http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html
>>
>> All work without namespaces...
>>
> 
> Let me tackle them in reverse order (the more debateable first....)
> 
> C) Yes, this is indeed simpler.  No namespaces is wonderful.  (PS I will 
>  declare here that I am no fan of XML, so less XML always keeps me happy)
> 
> The downside of this is that it "assumes" that you know all the valid 
> XML in advance, if any validation is going to be done.  I suppose that 
> you have options:
> 
> - 1.  Don't worry about validation at all.
> - 2.  Do validation and have some non-namespace way of knowing all the 
>     XSDs that contribute.
> 
> The problem really hits when you start to build SCA Assemblies using 
> tooling that is not part of Tuscany.  The SOA Tools project at Eclipse 
> comes to mind.  We may come up with some approach for Tuscany, but can 
> that also be used for the SOA Tools project?
> 
> Namespaces may be ugly but at least they represent a standard that all 
> can use....
> 
> B) This is the SCA spec approach.  I'd recommend at least supporting 
> this even if other techniques are also allowed.
> 
> A) Is really problematic.  It implies hacking the XSDs defined by the 
> SCA specs.  How will anyone know when they have violated the spec XSDs 
> that form part of the Portability conformance that is part of the value 
> of SCA (ie build and run my stuff on Tuscany and the same stuff should 
> work on Oracle's runtime, if I stick to the stuff defined in the SCA 
> specs...).
> 
> A will also imply the existence of at least 2 sets of "SCA XSDs" - the 
> spec ones and the Tuscany ones.  How will anyone know which one they've 
> got in their hands....?
> 
> So:
> 
> A) -1    not a good place to be
> B) +1    its the standard
> C) +0.5  I can envisage this as +1 if it is an optional setting that a 
> user can knowingly choose to use - as long as it is clear what they lose
> 
> 
> Yours,  Mike.
> 
> PS The Microsoft WCF config works without a namespace since I think it 
> is not extensible, unlike SCA which allows all kinds of extension.
> 
> PS 2 If anyone can think of a better way for SCA to handle its 
> extensibility, that will allow us to drop namespaces, the spec team will 
> be all ears.  The spec group debated the use of namespaces at some 
> length before adopting the current spec definition (and I was one of 
> those trying to keep namespaces out of it....).
> 
> 
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Mike Edwards <mi...@gmail.com>.

Folks,

In some ways, I'm glad I was on vacation while much of this debate 
raged!!   ;-)

Comments below.....

Jean-Sebastien Delfino wrote:

> [A] What we have right now, standard SCA extensions and tuscany 
> extensions sharing the standard SCA namespace
> (B) What IMO is a more correct use of XML namespaces, standard SCA 
> extensions in the standard SCA namespace, and Tuscany extensions in a 
> Tuscany namespace
> [C] What an application developer could write if we allowed namespaces 
> to be omitted
>......
> Now here are a few "side effects" :)
> 
> Option [A]
> - I cannot validate this composite against the standard SCA schemas 
> (it'll show errors in my XSD aware XML editor) our Tuscany extensions 
> violate the standard SCA namespace
> - I have one less namespace and prefix declaration to care about
> 
> Option [B]
> - I can validate this composite against the standard SCA schemas, as the 
> Tuscany extensions match the xsd:any namespace="##other" extensibility 
> points in the SCA schema
> - I have one more namespace and prefix declaration to write covering the 
> Tuscany extensions
> 
> Option [C]
> - I don't need to worry about namespaces, which are usually long and 
> error prone, writing the composite is simpler
> - I cannot validate this composite against the standard SCA schemas as 
> it does not declare namespaces
> 
> My preference is to do both:
> - [B], be correct with respect to our usage of XML schema, to make 
> people who care about XML schema validation and use XML schema tools happy
> - and [C] allow people who don't like namespaces to not have to write them
> 
> Why do I like [C] as well? Here are a few examples:
> 
> <html>
>    <body>
>       Hello! I can write XML without namespaces, isn't that nice?
>    </body>
> </html>
> 
> An axis2.xml configuration file
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml 
> 
> 
> An MS WCF configuration
> http://msdn2.microsoft.com/en-us/library/ms735103.aspx
> 
> A Tomcat server.xml file
> http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html
> 
> All work without namespaces...
>

Let me tackle them in reverse order (the more debateable first....)

C) Yes, this is indeed simpler.  No namespaces is wonderful.  (PS I will 
  declare here that I am no fan of XML, so less XML always keeps me happy)

The downside of this is that it "assumes" that you know all the valid 
XML in advance, if any validation is going to be done.  I suppose that 
you have options:

- 1.  Don't worry about validation at all.
- 2.  Do validation and have some non-namespace way of knowing all the 
     XSDs that contribute.

The problem really hits when you start to build SCA Assemblies using 
tooling that is not part of Tuscany.  The SOA Tools project at Eclipse 
comes to mind.  We may come up with some approach for Tuscany, but can 
that also be used for the SOA Tools project?

Namespaces may be ugly but at least they represent a standard that all 
can use....

B) This is the SCA spec approach.  I'd recommend at least supporting 
this even if other techniques are also allowed.

A) Is really problematic.  It implies hacking the XSDs defined by the 
SCA specs.  How will anyone know when they have violated the spec XSDs 
that form part of the Portability conformance that is part of the value 
of SCA (ie build and run my stuff on Tuscany and the same stuff should 
work on Oracle's runtime, if I stick to the stuff defined in the SCA 
specs...).

A will also imply the existence of at least 2 sets of "SCA XSDs" - the 
spec ones and the Tuscany ones.  How will anyone know which one they've 
got in their hands....?

So:

A) -1    not a good place to be
B) +1    its the standard
C) +0.5  I can envisage this as +1 if it is an optional setting that a 
user can knowingly choose to use - as long as it is clear what they lose

Yours,  Mike.

PS The Microsoft WCF config works without a namespace since I think it 
is not extensible, unlike SCA which allows all kinds of extension.

PS 2 If anyone can think of a better way for SCA to handle its 
extensibility, that will allow us to drop namespaces, the spec team will 
be all ears.  The spec group debated the use of namespaces at some 
length before adopting the current spec definition (and I was one of 
those trying to keep namespaces out of it....).

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Luciano Resende <lu...@gmail.com>.

Looks like option B is more "spec compliant" and more aligned to the
XML namespaces usage rules. Should I give it a try ?

On 8/19/07, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Here is my opinion about the three options:
>
> 1) -0.5 on A)
> 2) +1 on B)
> 3) -0.5 on C)
>
> A) violates the SCA assembly spec.
>
> 2535 ... New interface types, implementation types and binding types that
> are defined using
> 2536 this extensibility model, which are not part of these SCA
> specifications must be defined in
> 2537 namespaces other than the SCA namespace.
>
> C) IMO, the composite file should conform to the XSD defined by the SCA
> spec. The example listed under C) is not a valid SCA composite definition.
> We can make the "http://www.osoa.org/xmlns/sca/1.0" as the default namespace
> to avoid the repeating prefixes.
>
> B) is right usage of XML namespaces.
>
> Hopefully, the SCA tooling can help ease the XML namespace declarations.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jean-Sebastien Delfino" <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Sunday, August 19, 2007 5:07 PM
> Subject: Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all
> non-spec'd Tuscany extensions
>
>
> > Luciano Resende wrote:
> >> Sebastien wrote :
> >>
> >>> IMO application developers shouldn't have to suffer from the
> >>>
> >> complexity of XML...
> >>
> >>> How about supporting composites without namespace declarations at all?
> >>>
> >>
> >> I'm trying to understand all the proposals here, what would be the
> >> side effects of going with your proposal ? This seems like simple, and
> >> simple is good...
> >>
> >>
> >>
> >
> > Before getting into the side effects, here are three examples:
> >
> > [A] What we have right now, standard SCA extensions and tuscany extensions
> > sharing the standard SCA namespace
> >
> > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> >    targetNamespace="http://bigbank"
> >    xmlns:bb="http://bigbank"
> >    name="BigBank">
> >
> >    <component name="AccountServiceComponent">
> >        <service name="AccountService">
> >            <binding.jsonrpc uri="/AccountJSONService"/>
> >            <binding.ws
> > wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)"/>
> >            <binding.sca/>
> >        </service>
> >
> >        <implementation.java class="bigbank.account.AccountServiceImpl"/>
> >
> >        <reference name="accountDataService"
> > target="AccountDataServiceComponent"/>
> >        <reference name="calculatorService">
> >            <binding.rmi host="localhost" port="8099"
> > serviceName="CalculatorRMIService"/>
> >           </reference>
> >        <reference name="stockQuoteService">
> >            <binding.ws
> > wsdlElement="http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
> >        </reference>
> >          <property name="currency">EURO</property>
> >    </component>
> >
> >    <component name="AccountFeedComponent">
> >           <service name="Collection">
> >               <binding.rss uri="/rss"/>
> >               <binding.atom uri="/atom"/>
> >           </service>
> >        <implementation.java class="bigbank.account.feed.AccountFeedImpl"/>
> >        <reference name="accountService" target="AccountServiceComponent"/>
> >    </component>
> >
> >    <component name="AccountDataServiceComponent">
> >        <implementation.composite name="bb:AccountData"/>
> >    </component>
> >
> >    <component name="WebResourceComponent">
> >           <service name="Resource">
> >               <binding.resource uri="/"/>
> >           </service>
> >        <implementation.resource location="web"/>
> >    </component>
> >
> > </composite>
> >
> >
> > (B) What IMO is a more correct use of XML namespaces, standard SCA
> > extensions in the standard SCA namespace, and Tuscany extensions in a
> > Tuscany namespace
> >
> > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> >    xmlns:t="http://incubator.apache.org/xmlns/tuscany/1.0"
> >    targetNamespace="http://bigbank"
> >    xmlns:bb="http://bigbank"
> >    name="BigBank">
> >
> >    <component name="AccountServiceComponent">
> >        <service name="AccountService">
> >            <t:binding.jsonrpc uri="/AccountJSONService"/>
> >            <binding.ws
> > wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)"/>
> >            <binding.sca/>
> >        </service>
> >
> >        <implementation.java class="bigbank.account.AccountServiceImpl"/>
> >
> >        <reference name="accountDataService"
> > target="AccountDataServiceComponent"/>
> >        <reference name="calculatorService">
> >            <t:binding.rmi host="localhost" port="8099"
> > serviceName="CalculatorRMIService"/>
> >           </reference>
> >        <reference name="stockQuoteService">
> >            <binding.ws
> > wsdlElement="http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
> >        </reference>
> >          <property name="currency">EURO</property>
> >    </component>
> >
> >    <component name="AccountFeedComponent">
> >           <service name="Collection">
> >               <t:binding.rss uri="/rss"/>
> >               <t:binding.atom uri="/atom"/>
> >           </service>
> >        <implementation.java class="bigbank.account.feed.AccountFeedImpl"/>
> >        <reference name="accountService" target="AccountServiceComponent"/>
> >    </component>
> >
> >    <component name="AccountDataServiceComponent">
> >        <implementation.composite name="bb:AccountData"/>
> >    </component>
> >
> >    <component name="WebResourceComponent">
> >           <service name="Resource">
> >               <t:binding.resource uri="/"/>
> >           </service>
> >        <implementation.resource location="web"/>
> >    </component>
> >
> > </composite>
> >
> > [C] What an application developer could write if we allowed namespaces to
> > be omitted
> >
> > <composite
> >    name="BigBank">
> >
> >    <component name="AccountServiceComponent">
> >        <service name="AccountService">
> >            <binding.jsonrpc uri="/AccountJSONService"/>
> >            <binding.ws
> > wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)"/>
> >            <binding.sca/>
> >        </service>
> >
> >        <implementation.java class="bigbank.account.AccountServiceImpl"/>
> >
> >        <reference name="accountDataService"
> > target="AccountDataServiceComponent"/>
> >        <reference name="calculatorService">
> >            <binding.rmi host="localhost" port="8099"
> > serviceName="CalculatorRMIService"/>
> >           </reference>
> >        <reference name="stockQuoteService">
> >            <binding.ws
> > wsdlElement="http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
> >        </reference>
> >          <property name="currency">EURO</property>
> >    </component>
> >
> >    <component name="AccountFeedComponent">
> >           <service name="Collection">
> >               <binding.rss uri="/rss"/>
> >               <binding.atom uri="/atom"/>
> >           </service>
> >        <implementation.java class="bigbank.account.feed.AccountFeedImpl"/>
> >        <reference name="accountService" target="AccountServiceComponent"/>
> >    </component>
> >
> >    <component name="AccountDataServiceComponent">
> >        <implementation.composite name="AccountData"/>
> >    </component>
> >
> >    <component name="WebResourceComponent">
> >           <service name="Resource">
> >               <binding.resource uri="/"/>
> >           </service>
> >        <implementation.resource location="web"/>
> >    </component>
> >
> > </composite>
> >
> > Now here are a few "side effects" :)
> >
> > Option [A]
> > - I cannot validate this composite against the standard SCA schemas (it'll
> > show errors in my XSD aware XML editor) our Tuscany extensions violate the
> > standard SCA namespace
> > - I have one less namespace and prefix declaration to care about
> >
> > Option [B]
> > - I can validate this composite against the standard SCA schemas, as the
> > Tuscany extensions match the xsd:any namespace="##other" extensibility
> > points in the SCA schema
> > - I have one more namespace and prefix declaration to write covering the
> > Tuscany extensions
> >
> > Option [C]
> > - I don't need to worry about namespaces, which are usually long and error
> > prone, writing the composite is simpler
> > - I cannot validate this composite against the standard SCA schemas as it
> > does not declare namespaces
> >
> > My preference is to do both:
> > - [B], be correct with respect to our usage of XML schema, to make people
> > who care about XML schema validation and use XML schema tools happy
> > - and [C] allow people who don't like namespaces to not have to write them
> >
> > Why do I like [C] as well? Here are a few examples:
> >
> > <html>
> >    <body>
> >       Hello! I can write XML without namespaces, isn't that nice?
> >    </body>
> > </html>
> >
> > An axis2.xml configuration file
> > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml
> >
> > An MS WCF configuration
> > http://msdn2.microsoft.com/en-us/library/ms735103.aspx
> >
> > A Tomcat server.xml file
> > http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html
> >
> > All work without namespaces...
> >
> > --
> > 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
>
>


-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Raymond Feng <en...@gmail.com>.

Hi,

Here is my opinion about the three options:

1) -0.5 on A)
2) +1 on B)
3) -0.5 on C)

A) violates the SCA assembly spec.

2535 ... New interface types, implementation types and binding types that 
are defined using
2536 this extensibility model, which are not part of these SCA 
specifications must be defined in
2537 namespaces other than the SCA namespace.

C) IMO, the composite file should conform to the XSD defined by the SCA 
spec. The example listed under C) is not a valid SCA composite definition. 
We can make the "http://www.osoa.org/xmlns/sca/1.0" as the default namespace 
to avoid the repeating prefixes.

B) is right usage of XML namespaces.

Hopefully, the SCA tooling can help ease the XML namespace declarations.

Thanks,
Raymond

----- Original Message ----- 
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Sunday, August 19, 2007 5:07 PM
Subject: Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all 
non-spec'd Tuscany extensions


> Luciano Resende wrote:
>> Sebastien wrote :
>>
>>> IMO application developers shouldn't have to suffer from the
>>>
>> complexity of XML...
>>
>>> How about supporting composites without namespace declarations at all?
>>>
>>
>> I'm trying to understand all the proposals here, what would be the
>> side effects of going with your proposal ? This seems like simple, and
>> simple is good...
>>
>>
>>
>
> Before getting into the side effects, here are three examples:
>
> [A] What we have right now, standard SCA extensions and tuscany extensions 
> sharing the standard SCA namespace
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>    targetNamespace="http://bigbank"
>    xmlns:bb="http://bigbank"
>    name="BigBank">
>
>    <component name="AccountServiceComponent">
>        <service name="AccountService">
>            <binding.jsonrpc uri="/AccountJSONService"/>
>            <binding.ws 
> wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)"/>
>            <binding.sca/>
>        </service>
>
>        <implementation.java class="bigbank.account.AccountServiceImpl"/>
>
>        <reference name="accountDataService" 
> target="AccountDataServiceComponent"/>
>        <reference name="calculatorService">
>            <binding.rmi host="localhost" port="8099" 
> serviceName="CalculatorRMIService"/>
>           </reference>
>        <reference name="stockQuoteService">
>            <binding.ws 
> wsdlElement="http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
>        </reference>
>          <property name="currency">EURO</property>
>    </component>
>
>    <component name="AccountFeedComponent">
>           <service name="Collection">
>               <binding.rss uri="/rss"/>
>               <binding.atom uri="/atom"/>
>           </service>
>        <implementation.java class="bigbank.account.feed.AccountFeedImpl"/>
>        <reference name="accountService" target="AccountServiceComponent"/>
>    </component>
>
>    <component name="AccountDataServiceComponent">
>        <implementation.composite name="bb:AccountData"/>
>    </component>
>
>    <component name="WebResourceComponent">
>           <service name="Resource">
>               <binding.resource uri="/"/>
>           </service>
>        <implementation.resource location="web"/>
>    </component>
>
> </composite>
>
>
> (B) What IMO is a more correct use of XML namespaces, standard SCA 
> extensions in the standard SCA namespace, and Tuscany extensions in a 
> Tuscany namespace
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>    xmlns:t="http://incubator.apache.org/xmlns/tuscany/1.0"
>    targetNamespace="http://bigbank"
>    xmlns:bb="http://bigbank"
>    name="BigBank">
>
>    <component name="AccountServiceComponent">
>        <service name="AccountService">
>            <t:binding.jsonrpc uri="/AccountJSONService"/>
>            <binding.ws 
> wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)"/>
>            <binding.sca/>
>        </service>
>
>        <implementation.java class="bigbank.account.AccountServiceImpl"/>
>
>        <reference name="accountDataService" 
> target="AccountDataServiceComponent"/>
>        <reference name="calculatorService">
>            <t:binding.rmi host="localhost" port="8099" 
> serviceName="CalculatorRMIService"/>
>           </reference>
>        <reference name="stockQuoteService">
>            <binding.ws 
> wsdlElement="http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
>        </reference>
>          <property name="currency">EURO</property>
>    </component>
>
>    <component name="AccountFeedComponent">
>           <service name="Collection">
>               <t:binding.rss uri="/rss"/>
>               <t:binding.atom uri="/atom"/>
>           </service>
>        <implementation.java class="bigbank.account.feed.AccountFeedImpl"/>
>        <reference name="accountService" target="AccountServiceComponent"/>
>    </component>
>
>    <component name="AccountDataServiceComponent">
>        <implementation.composite name="bb:AccountData"/>
>    </component>
>
>    <component name="WebResourceComponent">
>           <service name="Resource">
>               <t:binding.resource uri="/"/>
>           </service>
>        <implementation.resource location="web"/>
>    </component>
>
> </composite>
>
> [C] What an application developer could write if we allowed namespaces to 
> be omitted
>
> <composite
>    name="BigBank">
>
>    <component name="AccountServiceComponent">
>        <service name="AccountService">
>            <binding.jsonrpc uri="/AccountJSONService"/>
>            <binding.ws 
> wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)"/>
>            <binding.sca/>
>        </service>
>
>        <implementation.java class="bigbank.account.AccountServiceImpl"/>
>
>        <reference name="accountDataService" 
> target="AccountDataServiceComponent"/>
>        <reference name="calculatorService">
>            <binding.rmi host="localhost" port="8099" 
> serviceName="CalculatorRMIService"/>
>           </reference>
>        <reference name="stockQuoteService">
>            <binding.ws 
> wsdlElement="http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
>        </reference>
>          <property name="currency">EURO</property>
>    </component>
>
>    <component name="AccountFeedComponent">
>           <service name="Collection">
>               <binding.rss uri="/rss"/>
>               <binding.atom uri="/atom"/>
>           </service>
>        <implementation.java class="bigbank.account.feed.AccountFeedImpl"/>
>        <reference name="accountService" target="AccountServiceComponent"/>
>    </component>
>
>    <component name="AccountDataServiceComponent">
>        <implementation.composite name="AccountData"/>
>    </component>
>
>    <component name="WebResourceComponent">
>           <service name="Resource">
>               <binding.resource uri="/"/>
>           </service>
>        <implementation.resource location="web"/>
>    </component>
>
> </composite>
>
> Now here are a few "side effects" :)
>
> Option [A]
> - I cannot validate this composite against the standard SCA schemas (it'll 
> show errors in my XSD aware XML editor) our Tuscany extensions violate the 
> standard SCA namespace
> - I have one less namespace and prefix declaration to care about
>
> Option [B]
> - I can validate this composite against the standard SCA schemas, as the 
> Tuscany extensions match the xsd:any namespace="##other" extensibility 
> points in the SCA schema
> - I have one more namespace and prefix declaration to write covering the 
> Tuscany extensions
>
> Option [C]
> - I don't need to worry about namespaces, which are usually long and error 
> prone, writing the composite is simpler
> - I cannot validate this composite against the standard SCA schemas as it 
> does not declare namespaces
>
> My preference is to do both:
> - [B], be correct with respect to our usage of XML schema, to make people 
> who care about XML schema validation and use XML schema tools happy
> - and [C] allow people who don't like namespaces to not have to write them
>
> Why do I like [C] as well? Here are a few examples:
>
> <html>
>    <body>
>       Hello! I can write XML without namespaces, isn't that nice?
>    </body>
> </html>
>
> An axis2.xml configuration file
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml
>
> An MS WCF configuration
> http://msdn2.microsoft.com/en-us/library/ms735103.aspx
>
> A Tomcat server.xml file
> http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html
>
> All work without namespaces...
>
> -- 
> 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: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jean-Sebastien Delfino <js...@apache.org>.

Luciano Resende wrote:
> Sebastien wrote :
>   
>> IMO application developers shouldn't have to suffer from the
>>     
> complexity of XML...
>   
>> How about supporting composites without namespace declarations at all?
>>     
>
> I'm trying to understand all the proposals here, what would be the
> side effects of going with your proposal ? This seems like simple, and
> simple is good...
>
>
>   

Before getting into the side effects, here are three examples:

[A] What we have right now, standard SCA extensions and tuscany 
extensions sharing the standard SCA namespace

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
    targetNamespace="http://bigbank"
    xmlns:bb="http://bigbank"
    name="BigBank">

    <component name="AccountServiceComponent">
        <service name="AccountService">
            <binding.jsonrpc uri="/AccountJSONService"/>
            <binding.ws 
wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)"/>
            <binding.sca/>
        </service>

        <implementation.java class="bigbank.account.AccountServiceImpl"/>

        <reference name="accountDataService" 
target="AccountDataServiceComponent"/>
        <reference name="calculatorService">
            <binding.rmi host="localhost" port="8099" 
serviceName="CalculatorRMIService"/>
           </reference>
        <reference name="stockQuoteService">
            <binding.ws 
wsdlElement="http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
        </reference>
          
        <property name="currency">EURO</property>
    </component>

    <component name="AccountFeedComponent">
           <service name="Collection">
               <binding.rss uri="/rss"/>
               <binding.atom uri="/atom"/>
           </service>
        <implementation.java class="bigbank.account.feed.AccountFeedImpl"/>
        <reference name="accountService" target="AccountServiceComponent"/>
    </component>

    <component name="AccountDataServiceComponent">
        <implementation.composite name="bb:AccountData"/>
    </component>

    <component name="WebResourceComponent">
           <service name="Resource">
               <binding.resource uri="/"/>
           </service>
        <implementation.resource location="web"/>
    </component>

</composite>


(B) What IMO is a more correct use of XML namespaces, standard SCA 
extensions in the standard SCA namespace, and Tuscany extensions in a 
Tuscany namespace

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
    xmlns:t="http://incubator.apache.org/xmlns/tuscany/1.0"
    targetNamespace="http://bigbank"
    xmlns:bb="http://bigbank"
    name="BigBank">

    <component name="AccountServiceComponent">
        <service name="AccountService">
            <t:binding.jsonrpc uri="/AccountJSONService"/>
            <binding.ws 
wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)"/>
            <binding.sca/>
        </service>

        <implementation.java class="bigbank.account.AccountServiceImpl"/>

        <reference name="accountDataService" 
target="AccountDataServiceComponent"/>
        <reference name="calculatorService">
            <t:binding.rmi host="localhost" port="8099" 
serviceName="CalculatorRMIService"/>
           </reference>
        <reference name="stockQuoteService">
            <binding.ws 
wsdlElement="http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
        </reference>
          
        <property name="currency">EURO</property>
    </component>

    <component name="AccountFeedComponent">
           <service name="Collection">
               <t:binding.rss uri="/rss"/>
               <t:binding.atom uri="/atom"/>
           </service>
        <implementation.java class="bigbank.account.feed.AccountFeedImpl"/>
        <reference name="accountService" target="AccountServiceComponent"/>
    </component>

    <component name="AccountDataServiceComponent">
        <implementation.composite name="bb:AccountData"/>
    </component>

    <component name="WebResourceComponent">
           <service name="Resource">
               <t:binding.resource uri="/"/>
           </service>
        <implementation.resource location="web"/>
    </component>

</composite>

[C] What an application developer could write if we allowed namespaces 
to be omitted

<composite
    name="BigBank">

    <component name="AccountServiceComponent">
        <service name="AccountService">
            <binding.jsonrpc uri="/AccountJSONService"/>
            <binding.ws 
wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)"/>
            <binding.sca/>
        </service>

        <implementation.java class="bigbank.account.AccountServiceImpl"/>

        <reference name="accountDataService" 
target="AccountDataServiceComponent"/>
        <reference name="calculatorService">
            <binding.rmi host="localhost" port="8099" 
serviceName="CalculatorRMIService"/>
           </reference>
        <reference name="stockQuoteService">
            <binding.ws 
wsdlElement="http://stockquote#wsdl.port(StockQuoteService/StockQuoteSoapPort)"/>
        </reference>
          
        <property name="currency">EURO</property>
    </component>

    <component name="AccountFeedComponent">
           <service name="Collection">
               <binding.rss uri="/rss"/>
               <binding.atom uri="/atom"/>
           </service>
        <implementation.java class="bigbank.account.feed.AccountFeedImpl"/>
        <reference name="accountService" target="AccountServiceComponent"/>
    </component>

    <component name="AccountDataServiceComponent">
        <implementation.composite name="AccountData"/>
    </component>

    <component name="WebResourceComponent">
           <service name="Resource">
               <binding.resource uri="/"/>
           </service>
        <implementation.resource location="web"/>
    </component>

</composite>

Now here are a few "side effects" :)

Option [A]
- I cannot validate this composite against the standard SCA schemas 
(it'll show errors in my XSD aware XML editor) our Tuscany extensions 
violate the standard SCA namespace
- I have one less namespace and prefix declaration to care about

Option [B]
- I can validate this composite against the standard SCA schemas, as the 
Tuscany extensions match the xsd:any namespace="##other" extensibility 
points in the SCA schema
- I have one more namespace and prefix declaration to write covering the 
Tuscany extensions

Option [C]
- I don't need to worry about namespaces, which are usually long and 
error prone, writing the composite is simpler
- I cannot validate this composite against the standard SCA schemas as 
it does not declare namespaces

My preference is to do both:
- [B], be correct with respect to our usage of XML schema, to make 
people who care about XML schema validation and use XML schema tools happy
- and [C] allow people who don't like namespaces to not have to write them

Why do I like [C] as well? Here are a few examples:

<html>
    <body>
       Hello! I can write XML without namespaces, isn't that nice?
    </body>
</html>

An axis2.xml configuration file
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml

An MS WCF configuration
http://msdn2.microsoft.com/en-us/library/ms735103.aspx

A Tomcat server.xml file
http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html

All work without namespaces...

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Luciano Resende <lu...@gmail.com>.

Sebastien wrote :
>IMO application developers shouldn't have to suffer from the
complexity of XML...
>How about supporting composites without namespace declarations at all?

I'm trying to understand all the proposals here, what would be the
side effects of going with your proposal ? This seems like simple, and
simple is good...


On 8/19/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> ant elder wrote:
> > The last comments have been in favour of keeping things as-is so how about
> > just doing nothing and letting this thread die.
> >
> >    ...ant
> >
> >
>
> Here are the last comments from the different people who contributed to
> this thread:
> - Mike, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21059.html
> - Luciano,
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21068.html
> - Simon, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21106.html
> - Sebastien,
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21113.html
> - Ant, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21117.html
>
> I don't see a consensus in favor of keeping things as-is in these comments.
>
> This has a significant impact on the programming model so IMO this JIRA
> issue needs a clear resolution.
>
> > On 8/19/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> >> ant elder wrote:
> >>
> >>> On 8/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >>>
> >>>
> >>>> ant elder wrote:
> >>>>
> >>>>
> >>>>> Taking that line of thought and you hit the long thread associated
> >>>>>
> >> with:
> >>
> >>>>>
> >>>>>
> >> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c6893F6F0-114E-4B65-8702-D117685C31CD@apache.org%3e
> >>
> >>>>> which is what I was hoping to quietly ignore by just keeping
> >>>>>
> >> everything
> >>
> >>>> in
> >>>>
> >>>>
> >>>>> the one SCA namespace.
> >>>>>
> >>>>>    ...ant
> >>>>>
> >>>>> On 8/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Wouldn't this cause breakage in the scenario that I described, where
> >>>>>> <foo> from Tuscany later turns into <foo> as part of SCA but with
> >>>>>>
> >> some
> >>
> >>>>>> differences?  Any SCDLs written to just use plain <foo> would break
> >>>>>> when Tuscany steps up to support the SCA <foo>.
> >>>>>>
> >>>>>>    Simon
> >>>>>>
> >>>>>> ant elder wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> How about having the Tuscany namespace extend the SCA one so you can
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> choose
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> to use that as the default namespace so as to avoid having to worry
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> about
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> all the namespace prefixes?
> >>>>>>>
> >>>>>>>    ...ant
> >>>>>>>
> >>>>>>> I don't really expect to win this debate now that the issue has been
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> brought
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> up, had just been hoping it wouldn't come up :)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> I didn't really want to reopen this debate either but I didn't
> >>>> understand both of your last comments so I guess I'm going to have to
> >>>> ask some questions...
> >>>>
> >>>> Ant, what did you mean by "having the Tuscany namespace extend the SCA
> >>>> one?"
> >>>>
> >>>>
> >>> I'm not actually sure, my xsd is a bit rusty, i vaguely thought there
> >>>
> >> was a
> >>
> >>> way to say something extend another namespace inheriting all the things
> >>>
> >> from
> >>
> >>> it, but a quick search for it now i cant find how to do that, is it not
> >>> possible?
> >>>
> >>> <snip>
> >>>
> >>> And also give my opinion:
> >>>
> >>>
> >>>> +0.5 if people want to keep Tuscany extensions in the SCA namespace for
> >>>> now, hoping that they make it to the SCA spec XSDs at some point
> >>>>
> >>>>
> >>> I'd be +1 on doing that. The easier we can make things for people trying
> >>>
> >> out
> >>
> >>> Tuscany the better IHMO.
> >>>
> >>>  ...ant
> >>>
> >>>
> >>>
> >> What's the conclusion here? I've seen different opinions from Mike,
> >> Simon, Luciano, Ant, myself. Do we need a vote to decide the next step?
> >>
> >> --
> >> Jean-Sebastien
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >>
> >
> >
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jean-Sebastien Delfino <js...@apache.org>.

ant elder wrote:
> The last comments have been in favour of keeping things as-is so how about
> just doing nothing and letting this thread die.
>
>    ...ant
>
>   

Here are the last comments from the different people who contributed to 
this thread:
- Mike, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21059.html
- Luciano, 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21068.html
- Simon, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21106.html
- Sebastien, 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21113.html
- Ant, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21117.html

I don't see a consensus in favor of keeping things as-is in these comments.

This has a significant impact on the programming model so IMO this JIRA 
issue needs a clear resolution.

> On 8/19/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>   
>> ant elder wrote:
>>     
>>> On 8/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>>
>>>       
>>>> ant elder wrote:
>>>>
>>>>         
>>>>> Taking that line of thought and you hit the long thread associated
>>>>>           
>> with:
>>     
>>>>>
>>>>>           
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c6893F6F0-114E-4B65-8702-D117685C31CD@apache.org%3e
>>     
>>>>> which is what I was hoping to quietly ignore by just keeping
>>>>>           
>> everything
>>     
>>>> in
>>>>
>>>>         
>>>>> the one SCA namespace.
>>>>>
>>>>>    ...ant
>>>>>
>>>>> On 8/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Wouldn't this cause breakage in the scenario that I described, where
>>>>>> <foo> from Tuscany later turns into <foo> as part of SCA but with
>>>>>>             
>> some
>>     
>>>>>> differences?  Any SCDLs written to just use plain <foo> would break
>>>>>> when Tuscany steps up to support the SCA <foo>.
>>>>>>
>>>>>>    Simon
>>>>>>
>>>>>> ant elder wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> How about having the Tuscany namespace extend the SCA one so you can
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> choose
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> to use that as the default namespace so as to avoid having to worry
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> about
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> all the namespace prefixes?
>>>>>>>
>>>>>>>    ...ant
>>>>>>>
>>>>>>> I don't really expect to win this debate now that the issue has been
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> brought
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> up, had just been hoping it wouldn't come up :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> I didn't really want to reopen this debate either but I didn't
>>>> understand both of your last comments so I guess I'm going to have to
>>>> ask some questions...
>>>>
>>>> Ant, what did you mean by "having the Tuscany namespace extend the SCA
>>>> one?"
>>>>
>>>>         
>>> I'm not actually sure, my xsd is a bit rusty, i vaguely thought there
>>>       
>> was a
>>     
>>> way to say something extend another namespace inheriting all the things
>>>       
>> from
>>     
>>> it, but a quick search for it now i cant find how to do that, is it not
>>> possible?
>>>
>>> <snip>
>>>
>>> And also give my opinion:
>>>
>>>       
>>>> +0.5 if people want to keep Tuscany extensions in the SCA namespace for
>>>> now, hoping that they make it to the SCA spec XSDs at some point
>>>>
>>>>         
>>> I'd be +1 on doing that. The easier we can make things for people trying
>>>       
>> out
>>     
>>> Tuscany the better IHMO.
>>>
>>>  ...ant
>>>
>>>
>>>       
>> What's the conclusion here? I've seen different opinions from Mike,
>> Simon, Luciano, Ant, myself. Do we need a vote to decide the next step?
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>>     
>
>   


-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by ant elder <an...@gmail.com>.

The last comments have been in favour of keeping things as-is so how about
just doing nothing and letting this thread die.

   ...ant

On 8/19/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 8/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> >> ant elder wrote:
> >>
> >>> Taking that line of thought and you hit the long thread associated
> with:
> >>>
> >>>
> >>>
> >>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c6893F6F0-114E-4B65-8702-D117685C31CD@apache.org%3e
> >>
> >>> which is what I was hoping to quietly ignore by just keeping
> everything
> >>>
> >> in
> >>
> >>> the one SCA namespace.
> >>>
> >>>    ...ant
> >>>
> >>> On 8/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >>>
> >>>
> >>>> Wouldn't this cause breakage in the scenario that I described, where
> >>>> <foo> from Tuscany later turns into <foo> as part of SCA but with
> some
> >>>> differences?  Any SCDLs written to just use plain <foo> would break
> >>>> when Tuscany steps up to support the SCA <foo>.
> >>>>
> >>>>    Simon
> >>>>
> >>>> ant elder wrote:
> >>>>
> >>>>
> >>>>
> >>>>> How about having the Tuscany namespace extend the SCA one so you can
> >>>>>
> >>>>>
> >>>> choose
> >>>>
> >>>>
> >>>>> to use that as the default namespace so as to avoid having to worry
> >>>>>
> >>>>>
> >>>> about
> >>>>
> >>>>
> >>>>> all the namespace prefixes?
> >>>>>
> >>>>>    ...ant
> >>>>>
> >>>>> I don't really expect to win this debate now that the issue has been
> >>>>>
> >>>>>
> >>>> brought
> >>>>
> >>>>
> >>>>> up, had just been hoping it wouldn't come up :)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >> I didn't really want to reopen this debate either but I didn't
> >> understand both of your last comments so I guess I'm going to have to
> >> ask some questions...
> >>
> >> Ant, what did you mean by "having the Tuscany namespace extend the SCA
> >> one?"
> >>
> >
> >
> > I'm not actually sure, my xsd is a bit rusty, i vaguely thought there
> was a
> > way to say something extend another namespace inheriting all the things
> from
> > it, but a quick search for it now i cant find how to do that, is it not
> > possible?
> >
> > <snip>
> >
> > And also give my opinion:
> >
> >> +0.5 if people want to keep Tuscany extensions in the SCA namespace for
> >> now, hoping that they make it to the SCA spec XSDs at some point
> >>
> >
> >
> > I'd be +1 on doing that. The easier we can make things for people trying
> out
> > Tuscany the better IHMO.
> >
> >  ...ant
> >
> >
>
> What's the conclusion here? I've seen different opinions from Mike,
> Simon, Luciano, Ant, myself. Do we need a vote to decide the next step?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jean-Sebastien Delfino <js...@apache.org>.

ant elder wrote:
> On 8/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>   
>> ant elder wrote:
>>     
>>> Taking that line of thought and you hit the long thread associated with:
>>>
>>>
>>>       
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c6893F6F0-114E-4B65-8702-D117685C31CD@apache.org%3e
>>     
>>> which is what I was hoping to quietly ignore by just keeping everything
>>>       
>> in
>>     
>>> the one SCA namespace.
>>>
>>>    ...ant
>>>
>>> On 8/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
>>>
>>>       
>>>> Wouldn't this cause breakage in the scenario that I described, where
>>>> <foo> from Tuscany later turns into <foo> as part of SCA but with some
>>>> differences?  Any SCDLs written to just use plain <foo> would break
>>>> when Tuscany steps up to support the SCA <foo>.
>>>>
>>>>    Simon
>>>>
>>>> ant elder wrote:
>>>>
>>>>
>>>>         
>>>>> How about having the Tuscany namespace extend the SCA one so you can
>>>>>
>>>>>           
>>>> choose
>>>>
>>>>         
>>>>> to use that as the default namespace so as to avoid having to worry
>>>>>
>>>>>           
>>>> about
>>>>
>>>>         
>>>>> all the namespace prefixes?
>>>>>
>>>>>    ...ant
>>>>>
>>>>> I don't really expect to win this debate now that the issue has been
>>>>>
>>>>>           
>>>> brought
>>>>
>>>>         
>>>>> up, had just been hoping it wouldn't come up :)
>>>>>
>>>>>
>>>>>
>>>>>           
>> I didn't really want to reopen this debate either but I didn't
>> understand both of your last comments so I guess I'm going to have to
>> ask some questions...
>>
>> Ant, what did you mean by "having the Tuscany namespace extend the SCA
>> one?"
>>     
>
>
> I'm not actually sure, my xsd is a bit rusty, i vaguely thought there was a
> way to say something extend another namespace inheriting all the things from
> it, but a quick search for it now i cant find how to do that, is it not
> possible?
>
> <snip>
>
> And also give my opinion:
>   
>> +0.5 if people want to keep Tuscany extensions in the SCA namespace for
>> now, hoping that they make it to the SCA spec XSDs at some point
>>     
>
>
> I'd be +1 on doing that. The easier we can make things for people trying out
> Tuscany the better IHMO.
>
>  ...ant
>
>   

What's the conclusion here? I've seen different opinions from Mike, 
Simon, Luciano, Ant, myself. Do we need a vote to decide the next step?

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by ant elder <an...@apache.org>.

On 8/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > Taking that line of thought and you hit the long thread associated with:
> >
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c6893F6F0-114E-4B65-8702-D117685C31CD@apache.org%3e
> >
> > which is what I was hoping to quietly ignore by just keeping everything
> in
> > the one SCA namespace.
> >
> >    ...ant
> >
> > On 8/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> >> Wouldn't this cause breakage in the scenario that I described, where
> >> <foo> from Tuscany later turns into <foo> as part of SCA but with some
> >> differences?  Any SCDLs written to just use plain <foo> would break
> >> when Tuscany steps up to support the SCA <foo>.
> >>
> >>    Simon
> >>
> >> ant elder wrote:
> >>
> >>
> >>> How about having the Tuscany namespace extend the SCA one so you can
> >>>
> >> choose
> >>
> >>> to use that as the default namespace so as to avoid having to worry
> >>>
> >> about
> >>
> >>> all the namespace prefixes?
> >>>
> >>>    ...ant
> >>>
> >>> I don't really expect to win this debate now that the issue has been
> >>>
> >> brought
> >>
> >>> up, had just been hoping it wouldn't come up :)
> >>>
> >>>
> >>>
>
> I didn't really want to reopen this debate either but I didn't
> understand both of your last comments so I guess I'm going to have to
> ask some questions...
>
> Ant, what did you mean by "having the Tuscany namespace extend the SCA
> one?"


I'm not actually sure, my xsd is a bit rusty, i vaguely thought there was a
way to say something extend another namespace inheriting all the things from
it, but a quick search for it now i cant find how to do that, is it not
possible?

<snip>

And also give my opinion:
> +0.5 if people want to keep Tuscany extensions in the SCA namespace for
> now, hoping that they make it to the SCA spec XSDs at some point


I'd be +1 on doing that. The easier we can make things for people trying out
Tuscany the better IHMO.

 ...ant

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jean-Sebastien Delfino <js...@apache.org>.

ant elder wrote:
> Taking that line of thought and you hit the long thread associated with:
>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c6893F6F0-114E-4B65-8702-D117685C31CD@apache.org%3e
>
> which is what I was hoping to quietly ignore by just keeping everything in
> the one SCA namespace.
>
>    ...ant
>
> On 8/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
>   
>> Wouldn't this cause breakage in the scenario that I described, where
>> <foo> from Tuscany later turns into <foo> as part of SCA but with some
>> differences?  Any SCDLs written to just use plain <foo> would break
>> when Tuscany steps up to support the SCA <foo>.
>>
>>    Simon
>>
>> ant elder wrote:
>>
>>     
>>> How about having the Tuscany namespace extend the SCA one so you can
>>>       
>> choose
>>     
>>> to use that as the default namespace so as to avoid having to worry
>>>       
>> about
>>     
>>> all the namespace prefixes?
>>>
>>>    ...ant
>>>
>>> I don't really expect to win this debate now that the issue has been
>>>       
>> brought
>>     
>>> up, had just been hoping it wouldn't come up :)
>>>
>>>
>>>       

I didn't really want to reopen this debate either but I didn't 
understand both of your last comments so I guess I'm going to have to 
ask some questions...

Ant, what did you mean by "having the Tuscany namespace extend the SCA one?"

Simon, I didn't understand your response either. Are you talking about 
an XSD element changing over time and when it'll change it'll break the 
runtime that supported the old one? Sure then... if the XSDs change then 
the runtime has to be updated as soon as you want to claim that you 
support the new one... I'm probably missing something really obvious :)

Also I thought it'd be useful to post concrete examples of what we're 
talking about:

What we currently have:

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
  targetNamespace="http://aggregator"
  name="FeedAggregator">

  <service name="atomSample" promote="AtomAggregator">
    <binding.atom  uri="http://localhost:8083/atomAggregator"/>
  </service>   

  <component name="AtomAggregator">
    <implementation.java class="feed.AggregatorImpl"/>   
    <reference name="feed1">
      <binding.atom uri="http://www.oreillynet.com/pub/feed/1"/>
    </reference>
    <reference name="feed2">           
      <binding.atom uri="http://www.apachenews.org/atom.xml"/>
    </reference>
    <property name="feedTitle">Atom Sample</property>   
  </component> 
</composite>

With a new Tuscany namespace:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
  xmlns:t="http://www.apache.org/xmlns/tuscany/1.0"
  targetNamespace="http://aggregator"
  name="FeedAggregator">

  <service name="atomSample" promote="AtomAggregator">
    <t:binding.atom  uri="http://localhost:8083/atomAggregator"/>
  </service>   

  <component name="AtomAggregator">
    <implementation.java class="feed.AggregatorImpl"/>   
    <reference name="feed1">
      <t:binding.atom uri="http://www.oreillynet.com/pub/feed/1"/>
    </reference>
    <reference name="feed2">           
      <t:binding.atom uri="http://www.apachenews.org/atom.xml"/>
    </reference>
    <property name="feedTitle">Atom Sample</property>   
  </component> 
</composite>


And also give my opinion:
+0.5 if people want to keep Tuscany extensions in the SCA namespace for 
now, hoping that they make it to the SCA spec XSDs at some point
+1 for one Tuscany namespace for all our extensions, as it clearly flags 
the Tuscany added value
-1 for one Tuscany namespace per extension as discussed in the long old 
thread you pointed, as it would be over complicated for application 
developers

Finally here's an idea to help put a new spin on that discussion :)
IMO application developers shouldn't have to suffer from the complexity 
of XML... How about supporting composites without namespace declarations 
at all?

Thoughts?

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by ant elder <an...@apache.org>.

Taking that line of thought and you hit the long thread associated with:

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c6893F6F0-114E-4B65-8702-D117685C31CD@apache.org%3e

which is what I was hoping to quietly ignore by just keeping everything in
the one SCA namespace.

   ...ant

On 8/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> Wouldn't this cause breakage in the scenario that I described, where
> <foo> from Tuscany later turns into <foo> as part of SCA but with some
> differences?  Any SCDLs written to just use plain <foo> would break
> when Tuscany steps up to support the SCA <foo>.
>
>    Simon
>
> ant elder wrote:
>
> > How about having the Tuscany namespace extend the SCA one so you can
> choose
> > to use that as the default namespace so as to avoid having to worry
> about
> > all the namespace prefixes?
> >
> >    ...ant
> >
> > I don't really expect to win this debate now that the issue has been
> brought
> > up, had just been hoping it wouldn't come up :)
> >
> >
> > On 8/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> >>PITA is a new one on me.  I usually use Google to help me in such
> >>cases, but most of the entries near the top of the list are about
> >>a kind of bread :-)
> >>
> >>I don't see this as such a big problem.  The average WSDL file
> >>seems to contain at least 3 different namespaces.  I think XML
> >>programmers are quite familiar with the need to define additional
> >>namespaces and how to do that.  A simple rule that everything
> >>from the SCA spec is in the SCA namespace and everything from
> >>Tuscany SCA is in the Tuscany SCA namespace will help them to know
> >>which namespace they should be using.
> >>
> >>+1 to the suggestion that we produce extremely good diagnostics to
> >>help people who get the namespace wrong.
> >>
> >>Also +1 to the suggestion that we take Tuscany extensions that we
> >>think should be part of the specs to the spec group for their
> >>consideration.  However, this does not avoid the need for multiple
> >>namespaces, because at any point in time we should expect to have
> >>some Tuscany extensions to SCA that are not (yet) part of the specs.
> >>This actually reinforces the importance of putting Tuscany extensions
> >>in a Tuscany namespace, because Tuscany's <foo> might get adopted
> >>as SCA's <foo> with subtle differences, and it will then be important
> >>for people to be able to write either <tuscany:foo> or <sca:foo> in
> >>their SCDL and get the correct semantics.
> >>
> >>   Simon
> >>
> >>ant elder wrote:
> >>
> >>
> >>>This is a real pity IMHO as it makes the SCDL significantly more
> >>>complicated, ugly and error prone, changing this namespace is going to
> >>
> >>do
> >>
> >>>nothing to help usability. I know line 2535 in the spec is clear, but
> >>
> >>the
> >>
> >>>actual SCA schema supports doing this doesn't it? Could we just ignore
> >>
> >>line
> >>
> >>>2535, or propose all the extensions we have as spec proposals, or
> >>
> >>something,
> >>
> >>>anything else to avoid this PITA?
> >>>
> >>>At the very least we'll need to hightlight a change like this very
> >>
> >>clearly
> >>
> >>>in the release notes and website doc on all the extensions, and ensure
> >>>there's a really explicit and helpful error message produced when you
> >>
> >>get
> >>
> >>>the namespace wrong.
> >>>
> >>>   ...ant
> >>>
> >>>On 8/2/07, Luciano Resende <lu...@gmail.com> wrote:
> >>>
> >>>
> >>>>I have reopened the JIRA and will give it a try...
> >>>>
> >>>>On 8/2/07, Mike Edwards <mi...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>>Folks,
> >>>>>
> >>>>>I agree with Simon's comment - this resolution violates the SCA spec.
> >>>>>You are not supposed to go adding stuff to the SCA namespace that is
> >>
> >>not
> >>
> >>>>>approved by the SCA spec process.  In particular, no additions to the
> >>>>>sca.xsd or sca-core.xsd are allowed.
> >>>>>
> >>>>>Yours,  Mike.
> >>>>>
> >>>>>ant elder (JIRA) wrote:
> >>>>>
> >>>>>
> >>>>>>    [
> >>>>
> >>>>
> >>
> https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> >>]
> >>
> >>>>>>ant elder closed TUSCANY-1053.
> >>>>>>------------------------------
> >>>>>>
> >>>>>>   Resolution: Fixed
> >>>>>>
> >>>>>>Closing as it looks like we've standardized on using the SCA
> namespace
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Use a Tuscany namespace for all non-spec'd Tuscany extensions
> >>>>>>>-------------------------------------------------------------
> >>>>>>>
> >>>>>>>               Key: TUSCANY-1053
> >>>>>>>               URL:
> >>>>
> >>>>https://issues.apache.org/jira/browse/TUSCANY-1053
> >>>>
> >>>>
> >>>>>>>           Project: Tuscany
> >>>>>>>        Issue Type: Improvement
> >>>>>>>        Components: Java SCA Assembly Model
> >>>>>>>  Affects Versions: Java-SCA-Next
> >>>>>>>          Reporter: ant elder
> >>>>>>>          Assignee: ant elder
> >>>>>>>           Fix For: Java-SCA-Next
> >>>>>>>
> >>>>>>>
> >>>>>>>Currently Tsucany extensions use SCDL elements is varrious
> different
> >>>>
> >>>>namespaces. There should be a single Tuscany namespace that extensions
> >>
> >>not
> >>
> >>>>defined by SCA spec's should use. See
> >>>>
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e
> >>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>--
> >>>>Luciano Resende
> >>>>Apache Tuscany Committer
> >>>>http://people.apache.org/~lresende
> >>>>http://lresende.blogspot.com/
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>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: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Simon Nash <na...@hursley.ibm.com>.

Wouldn't this cause breakage in the scenario that I described, where
<foo> from Tuscany later turns into <foo> as part of SCA but with some
differences?  Any SCDLs written to just use plain <foo> would break
when Tuscany steps up to support the SCA <foo>.

   Simon

ant elder wrote:

> How about having the Tuscany namespace extend the SCA one so you can choose
> to use that as the default namespace so as to avoid having to worry about
> all the namespace prefixes?
> 
>    ...ant
> 
> I don't really expect to win this debate now that the issue has been brought
> up, had just been hoping it wouldn't come up :)
> 
> 
> On 8/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
> 
>>PITA is a new one on me.  I usually use Google to help me in such
>>cases, but most of the entries near the top of the list are about
>>a kind of bread :-)
>>
>>I don't see this as such a big problem.  The average WSDL file
>>seems to contain at least 3 different namespaces.  I think XML
>>programmers are quite familiar with the need to define additional
>>namespaces and how to do that.  A simple rule that everything
>>from the SCA spec is in the SCA namespace and everything from
>>Tuscany SCA is in the Tuscany SCA namespace will help them to know
>>which namespace they should be using.
>>
>>+1 to the suggestion that we produce extremely good diagnostics to
>>help people who get the namespace wrong.
>>
>>Also +1 to the suggestion that we take Tuscany extensions that we
>>think should be part of the specs to the spec group for their
>>consideration.  However, this does not avoid the need for multiple
>>namespaces, because at any point in time we should expect to have
>>some Tuscany extensions to SCA that are not (yet) part of the specs.
>>This actually reinforces the importance of putting Tuscany extensions
>>in a Tuscany namespace, because Tuscany's <foo> might get adopted
>>as SCA's <foo> with subtle differences, and it will then be important
>>for people to be able to write either <tuscany:foo> or <sca:foo> in
>>their SCDL and get the correct semantics.
>>
>>   Simon
>>
>>ant elder wrote:
>>
>>
>>>This is a real pity IMHO as it makes the SCDL significantly more
>>>complicated, ugly and error prone, changing this namespace is going to
>>
>>do
>>
>>>nothing to help usability. I know line 2535 in the spec is clear, but
>>
>>the
>>
>>>actual SCA schema supports doing this doesn't it? Could we just ignore
>>
>>line
>>
>>>2535, or propose all the extensions we have as spec proposals, or
>>
>>something,
>>
>>>anything else to avoid this PITA?
>>>
>>>At the very least we'll need to hightlight a change like this very
>>
>>clearly
>>
>>>in the release notes and website doc on all the extensions, and ensure
>>>there's a really explicit and helpful error message produced when you
>>
>>get
>>
>>>the namespace wrong.
>>>
>>>   ...ant
>>>
>>>On 8/2/07, Luciano Resende <lu...@gmail.com> wrote:
>>>
>>>
>>>>I have reopened the JIRA and will give it a try...
>>>>
>>>>On 8/2/07, Mike Edwards <mi...@gmail.com> wrote:
>>>>
>>>>
>>>>>Folks,
>>>>>
>>>>>I agree with Simon's comment - this resolution violates the SCA spec.
>>>>>You are not supposed to go adding stuff to the SCA namespace that is
>>
>>not
>>
>>>>>approved by the SCA spec process.  In particular, no additions to the
>>>>>sca.xsd or sca-core.xsd are allowed.
>>>>>
>>>>>Yours,  Mike.
>>>>>
>>>>>ant elder (JIRA) wrote:
>>>>>
>>>>>
>>>>>>    [
>>>>
>>>>
>>https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>]
>>
>>>>>>ant elder closed TUSCANY-1053.
>>>>>>------------------------------
>>>>>>
>>>>>>   Resolution: Fixed
>>>>>>
>>>>>>Closing as it looks like we've standardized on using the SCA namespace
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Use a Tuscany namespace for all non-spec'd Tuscany extensions
>>>>>>>-------------------------------------------------------------
>>>>>>>
>>>>>>>               Key: TUSCANY-1053
>>>>>>>               URL:
>>>>
>>>>https://issues.apache.org/jira/browse/TUSCANY-1053
>>>>
>>>>
>>>>>>>           Project: Tuscany
>>>>>>>        Issue Type: Improvement
>>>>>>>        Components: Java SCA Assembly Model
>>>>>>>  Affects Versions: Java-SCA-Next
>>>>>>>          Reporter: ant elder
>>>>>>>          Assignee: ant elder
>>>>>>>           Fix For: Java-SCA-Next
>>>>>>>
>>>>>>>
>>>>>>>Currently Tsucany extensions use SCDL elements is varrious different
>>>>
>>>>namespaces. There should be a single Tuscany namespace that extensions
>>
>>not
>>
>>>>defined by SCA spec's should use. See
>>>>
>>
>>http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e
>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>--
>>>>Luciano Resende
>>>>Apache Tuscany Committer
>>>>http://people.apache.org/~lresende
>>>>http://lresende.blogspot.com/
>>>>
>>>>---------------------------------------------------------------------
>>>>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: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by ant elder <an...@apache.org>.

How about having the Tuscany namespace extend the SCA one so you can choose
to use that as the default namespace so as to avoid having to worry about
all the namespace prefixes?

   ...ant

I don't really expect to win this debate now that the issue has been brought
up, had just been hoping it wouldn't come up :)


On 8/3/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> PITA is a new one on me.  I usually use Google to help me in such
> cases, but most of the entries near the top of the list are about
> a kind of bread :-)
>
> I don't see this as such a big problem.  The average WSDL file
> seems to contain at least 3 different namespaces.  I think XML
> programmers are quite familiar with the need to define additional
> namespaces and how to do that.  A simple rule that everything
> from the SCA spec is in the SCA namespace and everything from
> Tuscany SCA is in the Tuscany SCA namespace will help them to know
> which namespace they should be using.
>
> +1 to the suggestion that we produce extremely good diagnostics to
> help people who get the namespace wrong.
>
> Also +1 to the suggestion that we take Tuscany extensions that we
> think should be part of the specs to the spec group for their
> consideration.  However, this does not avoid the need for multiple
> namespaces, because at any point in time we should expect to have
> some Tuscany extensions to SCA that are not (yet) part of the specs.
> This actually reinforces the importance of putting Tuscany extensions
> in a Tuscany namespace, because Tuscany's <foo> might get adopted
> as SCA's <foo> with subtle differences, and it will then be important
> for people to be able to write either <tuscany:foo> or <sca:foo> in
> their SCDL and get the correct semantics.
>
>    Simon
>
> ant elder wrote:
>
> > This is a real pity IMHO as it makes the SCDL significantly more
> > complicated, ugly and error prone, changing this namespace is going to
> do
> > nothing to help usability. I know line 2535 in the spec is clear, but
> the
> > actual SCA schema supports doing this doesn't it? Could we just ignore
> line
> > 2535, or propose all the extensions we have as spec proposals, or
> something,
> > anything else to avoid this PITA?
> >
> > At the very least we'll need to hightlight a change like this very
> clearly
> > in the release notes and website doc on all the extensions, and ensure
> > there's a really explicit and helpful error message produced when you
> get
> > the namespace wrong.
> >
> >    ...ant
> >
> > On 8/2/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> >>I have reopened the JIRA and will give it a try...
> >>
> >>On 8/2/07, Mike Edwards <mi...@gmail.com> wrote:
> >>
> >>>Folks,
> >>>
> >>>I agree with Simon's comment - this resolution violates the SCA spec.
> >>>You are not supposed to go adding stuff to the SCA namespace that is
> not
> >>>approved by the SCA spec process.  In particular, no additions to the
> >>>sca.xsd or sca-core.xsd are allowed.
> >>>
> >>>Yours,  Mike.
> >>>
> >>>ant elder (JIRA) wrote:
> >>>
> >>>>     [
> >>
> >>
> https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> >>
> >>>>ant elder closed TUSCANY-1053.
> >>>>------------------------------
> >>>>
> >>>>    Resolution: Fixed
> >>>>
> >>>>Closing as it looks like we've standardized on using the SCA namespace
> >>>>
> >>>>
> >>>>>Use a Tuscany namespace for all non-spec'd Tuscany extensions
> >>>>>-------------------------------------------------------------
> >>>>>
> >>>>>                Key: TUSCANY-1053
> >>>>>                URL:
> >>
> >>https://issues.apache.org/jira/browse/TUSCANY-1053
> >>
> >>>>>            Project: Tuscany
> >>>>>         Issue Type: Improvement
> >>>>>         Components: Java SCA Assembly Model
> >>>>>   Affects Versions: Java-SCA-Next
> >>>>>           Reporter: ant elder
> >>>>>           Assignee: ant elder
> >>>>>            Fix For: Java-SCA-Next
> >>>>>
> >>>>>
> >>>>>Currently Tsucany extensions use SCDL elements is varrious different
> >>
> >>namespaces. There should be a single Tuscany namespace that extensions
> not
> >>defined by SCA spec's should use. See
> >>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e
> >>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>
> >>
> >>
> >>--
> >>Luciano Resende
> >>Apache Tuscany Committer
> >>http://people.apache.org/~lresende
> >>http://lresende.blogspot.com/
> >>
> >>---------------------------------------------------------------------
> >>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: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Simon Nash <na...@hursley.ibm.com>.

PITA is a new one on me.  I usually use Google to help me in such
cases, but most of the entries near the top of the list are about
a kind of bread :-)

I don't see this as such a big problem.  The average WSDL file
seems to contain at least 3 different namespaces.  I think XML
programmers are quite familiar with the need to define additional
namespaces and how to do that.  A simple rule that everything
from the SCA spec is in the SCA namespace and everything from
Tuscany SCA is in the Tuscany SCA namespace will help them to know
which namespace they should be using.

+1 to the suggestion that we produce extremely good diagnostics to
help people who get the namespace wrong.

Also +1 to the suggestion that we take Tuscany extensions that we
think should be part of the specs to the spec group for their
consideration.  However, this does not avoid the need for multiple
namespaces, because at any point in time we should expect to have
some Tuscany extensions to SCA that are not (yet) part of the specs.
This actually reinforces the importance of putting Tuscany extensions
in a Tuscany namespace, because Tuscany's <foo> might get adopted
as SCA's <foo> with subtle differences, and it will then be important
for people to be able to write either <tuscany:foo> or <sca:foo> in
their SCDL and get the correct semantics.

   Simon

ant elder wrote:

> This is a real pity IMHO as it makes the SCDL significantly more
> complicated, ugly and error prone, changing this namespace is going to do
> nothing to help usability. I know line 2535 in the spec is clear, but the
> actual SCA schema supports doing this doesn't it? Could we just ignore line
> 2535, or propose all the extensions we have as spec proposals, or something,
> anything else to avoid this PITA?
> 
> At the very least we'll need to hightlight a change like this very clearly
> in the release notes and website doc on all the extensions, and ensure
> there's a really explicit and helpful error message produced when you get
> the namespace wrong.
> 
>    ...ant
> 
> On 8/2/07, Luciano Resende <lu...@gmail.com> wrote:
> 
>>I have reopened the JIRA and will give it a try...
>>
>>On 8/2/07, Mike Edwards <mi...@gmail.com> wrote:
>>
>>>Folks,
>>>
>>>I agree with Simon's comment - this resolution violates the SCA spec.
>>>You are not supposed to go adding stuff to the SCA namespace that is not
>>>approved by the SCA spec process.  In particular, no additions to the
>>>sca.xsd or sca-core.xsd are allowed.
>>>
>>>Yours,  Mike.
>>>
>>>ant elder (JIRA) wrote:
>>>
>>>>     [
>>
>>https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>
>>>>ant elder closed TUSCANY-1053.
>>>>------------------------------
>>>>
>>>>    Resolution: Fixed
>>>>
>>>>Closing as it looks like we've standardized on using the SCA namespace
>>>>
>>>>
>>>>>Use a Tuscany namespace for all non-spec'd Tuscany extensions
>>>>>-------------------------------------------------------------
>>>>>
>>>>>                Key: TUSCANY-1053
>>>>>                URL:
>>
>>https://issues.apache.org/jira/browse/TUSCANY-1053
>>
>>>>>            Project: Tuscany
>>>>>         Issue Type: Improvement
>>>>>         Components: Java SCA Assembly Model
>>>>>   Affects Versions: Java-SCA-Next
>>>>>           Reporter: ant elder
>>>>>           Assignee: ant elder
>>>>>            Fix For: Java-SCA-Next
>>>>>
>>>>>
>>>>>Currently Tsucany extensions use SCDL elements is varrious different
>>
>>namespaces. There should be a single Tuscany namespace that extensions not
>>defined by SCA spec's should use. See
>>http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e
>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>>--
>>Luciano Resende
>>Apache Tuscany Committer
>>http://people.apache.org/~lresende
>>http://lresende.blogspot.com/
>>
>>---------------------------------------------------------------------
>>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: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by ant elder <an...@gmail.com>.

This is a real pity IMHO as it makes the SCDL significantly more
complicated, ugly and error prone, changing this namespace is going to do
nothing to help usability. I know line 2535 in the spec is clear, but the
actual SCA schema supports doing this doesn't it? Could we just ignore line
2535, or propose all the extensions we have as spec proposals, or something,
anything else to avoid this PITA?

At the very least we'll need to hightlight a change like this very clearly
in the release notes and website doc on all the extensions, and ensure
there's a really explicit and helpful error message produced when you get
the namespace wrong.

   ...ant

On 8/2/07, Luciano Resende <lu...@gmail.com> wrote:
>
> I have reopened the JIRA and will give it a try...
>
> On 8/2/07, Mike Edwards <mi...@gmail.com> wrote:
> > Folks,
> >
> > I agree with Simon's comment - this resolution violates the SCA spec.
> > You are not supposed to go adding stuff to the SCA namespace that is not
> > approved by the SCA spec process.  In particular, no additions to the
> > sca.xsd or sca-core.xsd are allowed.
> >
> > Yours,  Mike.
> >
> > ant elder (JIRA) wrote:
> > >      [
> https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
> > >
> > > ant elder closed TUSCANY-1053.
> > > ------------------------------
> > >
> > >     Resolution: Fixed
> > >
> > > Closing as it looks like we've standardized on using the SCA namespace
> > >
> > >> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> > >> -------------------------------------------------------------
> > >>
> > >>                 Key: TUSCANY-1053
> > >>                 URL:
> https://issues.apache.org/jira/browse/TUSCANY-1053
> > >>             Project: Tuscany
> > >>          Issue Type: Improvement
> > >>          Components: Java SCA Assembly Model
> > >>    Affects Versions: Java-SCA-Next
> > >>            Reporter: ant elder
> > >>            Assignee: ant elder
> > >>             Fix For: Java-SCA-Next
> > >>
> > >>
> > >> Currently Tsucany extensions use SCDL elements is varrious different
> namespaces. There should be a single Tuscany namespace that extensions not
> defined by SCA spec's should use. See
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Luciano Resende <lu...@gmail.com>.

I have reopened the JIRA and will give it a try...

On 8/2/07, Mike Edwards <mi...@gmail.com> wrote:
> Folks,
>
> I agree with Simon's comment - this resolution violates the SCA spec.
> You are not supposed to go adding stuff to the SCA namespace that is not
> approved by the SCA spec process.  In particular, no additions to the
> sca.xsd or sca-core.xsd are allowed.
>
> Yours,  Mike.
>
> ant elder (JIRA) wrote:
> >      [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> >
> > ant elder closed TUSCANY-1053.
> > ------------------------------
> >
> >     Resolution: Fixed
> >
> > Closing as it looks like we've standardized on using the SCA namespace
> >
> >> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> >> -------------------------------------------------------------
> >>
> >>                 Key: TUSCANY-1053
> >>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1053
> >>             Project: Tuscany
> >>          Issue Type: Improvement
> >>          Components: Java SCA Assembly Model
> >>    Affects Versions: Java-SCA-Next
> >>            Reporter: ant elder
> >>            Assignee: ant elder
> >>             Fix For: Java-SCA-Next
> >>
> >>
> >> Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Mike Edwards <mi...@gmail.com>.

Folks,

I agree with Simon's comment - this resolution violates the SCA spec. 
You are not supposed to go adding stuff to the SCA namespace that is not 
approved by the SCA spec process.  In particular, no additions to the 
sca.xsd or sca-core.xsd are allowed.

Yours,  Mike.

ant elder (JIRA) wrote:
>      [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> 
> ant elder closed TUSCANY-1053.
> ------------------------------
> 
>     Resolution: Fixed
> 
> Closing as it looks like we've standardized on using the SCA namespace
> 
>> Use a Tuscany namespace for all non-spec'd Tuscany extensions
>> -------------------------------------------------------------
>>
>>                 Key: TUSCANY-1053
>>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1053
>>             Project: Tuscany
>>          Issue Type: Improvement
>>          Components: Java SCA Assembly Model
>>    Affects Versions: Java-SCA-Next
>>            Reporter: ant elder
>>            Assignee: ant elder
>>             Fix For: Java-SCA-Next
>>
>>
>> Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

[jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by "ant elder (JIRA)" <tu...@ws.apache.org>.

     [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ant elder closed TUSCANY-1053.
------------------------------

    Resolution: Fixed

Closing as it looks like we've standardized on using the SCA namespace

> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> -------------------------------------------------------------
>
>                 Key: TUSCANY-1053
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1053
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SCA Assembly Model
>    Affects Versions: Java-SCA-Next
>            Reporter: ant elder
>            Assignee: ant elder
>             Fix For: Java-SCA-Next
>
>
> Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

[jira] Reopened: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by "Luciano Resende (JIRA)" <tu...@ws.apache.org>.

     [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luciano Resende reopened TUSCANY-1053:
--------------------------------------

      Assignee: Luciano Resende  (was: ant elder)

Reopening per latest discussion comments :
"...this resolution violates the SCA spec.
You are not supposed to go adding stuff to the SCA namespace that is not
approved by the SCA spec process.  In particular, no additions to the
sca.xsd or sca-core.xsd are allowed."

> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> -------------------------------------------------------------
>
>                 Key: TUSCANY-1053
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1053
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SCA Assembly Model
>    Affects Versions: Java-SCA-Next
>            Reporter: ant elder
>            Assignee: Luciano Resende
>             Fix For: Java-SCA-Next
>
>
> Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

[jira] Resolved: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by "Luciano Resende (JIRA)" <tu...@ws.apache.org>.

     [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luciano Resende resolved TUSCANY-1053.
--------------------------------------

    Resolution: Fixed

Check discussion thread for discussion on aprach taken
   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21946.html

Done under revision #568830


> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> -------------------------------------------------------------
>
>                 Key: TUSCANY-1053
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1053
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SCA Assembly Model
>    Affects Versions: Java-SCA-Next
>            Reporter: ant elder
>            Assignee: Luciano Resende
>             Fix For: Java-SCA-Next
>
>
> Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

[jira] Updated: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by "Jim Marino (JIRA)" <tu...@ws.apache.org>.

     [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jim Marino updated TUSCANY-1053:
--------------------------------

    Affects Version/s:     (was: Java-M2)
                       Java-SCA-2.0-Alpha
        Fix Version/s:     (was: Java-SCA-M3)
                       Wish list

There hasn't yet been agreement on how best to achieve this. Pushing out for now until there is consensus on a solution.

> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> -------------------------------------------------------------
>
>                 Key: TUSCANY-1053
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1053
>             Project: Tuscany
>          Issue Type: Improvement
>    Affects Versions: Java-SCA-2.0-Alpha
>            Reporter: ant elder
>         Assigned To: ant elder
>             Fix For: Wish list
>
>
> Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

[jira] Updated: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by "Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>.

     [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Sebastien Delfino updated TUSCANY-1053:
--------------------------------------------

    Priority: Major  (was: Minor)

Changing priority to major as it affects the programming model, samples, and many test cases.

> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> -------------------------------------------------------------
>
>                 Key: TUSCANY-1053
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1053
>             Project: Tuscany
>          Issue Type: Improvement
>    Affects Versions: Java-M2
>            Reporter: ant elder
>             Fix For: Java-M3
>
>
> Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jeremy Boynes <jb...@apache.org>.

There is a good article describing the issue here:
http://www.xml.com/pub/a/2003/12/03/versioning.html

Key points are 8 and 9: 8 says that is you have a strictly compatible  
schema change you may be able to reuse an existing namespace (and  
should if you can), whereas 9 says that in the face of an  
incompatible change then you must use a new namespace.

Compatible changes are enabled through the use of extension elements  
and allowing nodes that are unable to process them to ignore them  
(including a mustUnderstand mechanism to control this behaviour).  
This means that documents may be interpreted differently on different  
platforms which is generally a good thing to allow but is bad in our  
case as we need consistency across an SCA domain.

An additional concern that impacts us is that the SCA assembly is a  
single construct derived from multiple XML documents rather than a  
bunch of independent documents. We need consistent definition across  
the documents used to define the assembly which means that liberal  
parsing of different documents will cause problems.

On Jan 29, 2007, at 7:39 PM, Jean-Sebastien Delfino wrote:

> Comments inline.
>
> Jeremy Boynes wrote:
>> There are two concrete issues.
>>
>> Firstly, with the XSD for the namespace spread over so many files,  
>> how does a user set up a tool to validate an XML document? They  
>> can add schemaLocation elements as hints but that is more complex  
>> than the separate namespaces. We can produce a single document  
>> that includes the others but that couples them together and  
>> requires us to version them all together.
>>
>
> This is usually specific to the tool. For example with the Eclipse  
> XML tools you register your XSD in the Eclipse XML catalog. To  
> validate SCDL composites using a set of SCDL extensions, you could  
> just give your tool an XSD file including the XSD of the particular  
> extensions. The user could write this XSD himself, or we could  
> provide a very simple tool or maybe even just a script producing  
> the XSD for him from the selected extensions for example. The  
> single namespace approach is definitely simpler for users than  
> having them declare so many namespaces, prefixes and  
> schemaLocations in all their .composite and .componentType files.

You keep describing mechanics without any of the consequences. The  
consequence of this is to combine all schema fragments from separate  
files into one schema document. This process has constraints,  
specifically that all these fragments are compatible with each other.  
This requires coordination between all fragment authors to ensure  
this consistency coupling their development together.

It does not matter if the user combines these themselves or if the  
runtime combines them automatically as described in the previous  
proposal, combination is still occurring.

The single namespace goal is a noble ideal but we have to deal with  
reality and in reality versioning XML namespaces has well documented  
issues. I laud the ideal but before we combine all our XML into one  
namespace and couple all the extensions together I would like to see  
a solution proposed for these issues.

>
>> Secondly, suppose we release kernel and ruby extension using V1.0  
>> of a namespace. We then release V1.1 of the kernel which makes  
>> schema changes so we need a new version of its schema, say 1.1;  
>> this requires a new V1.1 namespace. How does a user validate the  
>> V1.1 kernel XML with V1.0 XML for the ruby extension? The same  
>> issue applies as new versions of the ruby or any other extension  
>> are produced.
>
> I'm lost, sorry. It would help to go through a real concrete  
> example. The Ruby XSD defines a RubyImplementation complex type  
> extending the OSOA SCA base Implementation complex type, and an  
> implementation.ruby global element with substitutionGroup = "the  
> OSOA SCA implementationGroup" . It has no dependencies on another  
> Tuscany kernel XSD. I'm actually not sure what you mean by "kernel  
> XML". As far as I know there is no "kernel XSD" and I don't see how  
> some "kernel XML" would reference a Ruby component. Can you help me  
> understand with a real example? Thanks.

Simplified schemas:
kernel.xsd:
   <schema targetNamespace="http://tuscany/V1.0">
      ... some definitions
   </schema>
ruby.xsd:
   <schema targetNamespace="http://tuscany/V1.0">
      <element name="implementation.ruby>
         <attribute name="file" type="xs:string"/>
      </element>
   </schema>

We make a change to the kernel and add/remove/update some definitions  
and publish this as 1.1:
kernel11.xsd:
   <schema targetNamespace="http://tuscany/V1.1">
      ... some definitions
   </schema>

No change is made to the Ruby extension so it is still using 1.0 -  
how does the user use the implementation.ruby element in a document  
where the referenced namespace is http://tuscany/V1.1 without  
specifying the 1.0 namespace for it?

>>
>> The scheme you describe allows users to reuse the same namespace  
>> because it does not change the namespace when parts of the schema  
>> are released. This means there are multiple definitions of the  
>> same localPart in that namespace which is well known as being a  
>> real issue.
>>
>> This is generally understood enough that there was a explicit  
>> decision at the Assembly f2f last week (which we both attended) to  
>> discourage this redefinition in SCA schemas due to the problems it  
>> causes. Heck, we probably spent half the meeting discussing  
>> mechanisms to cope with poor schemas that already suffer from this  
>> problem - we do not need to make Tuscany's some of those.
>>
>
> We spent a lot of time discussing the usage of namespaces in SCA  
> applications but we did not change at all to use different  
> namespaces for the different SCA specifications. Maybe you are  
> confusing the SCA SCDL schema and user schemas used in an SCA  
> application? As far as I know, binding and  component  
> implementation type extensions (implementation.java, binding.ws,  
> binding.jms,  etc) are still in a single namespace, still using a  
> '.' notation to build unique names in that single namespace. I  
> think that this is an important characteristic of the SCA model, we  
> are trying to avoid an unnecessary proliferation of namespaces. I  
> want to keep the same approach in Tuscany: keep the programming  
> model simple.

No, I'm not confused - we spent the meeting "discussing mechanisms to  
cope with poor schemas that already suffer from this problem [of type  
redefinition caused by poor versioning]." I'm all in favour of  
avoiding unnecessary proliferation of namespaces but I am also aware  
that in reality some proliferation is necessary. If we are to  
encourage development and release of extensions (which benefits users  
as they get more functionality) then an appropriate use of namespaces  
is necessary.

--
Jeremy

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jean-Sebastien Delfino <js...@apache.org>.

Comments inline.

Jeremy Boynes wrote:
> There are two concrete issues.
>
> Firstly, with the XSD for the namespace spread over so many files, how 
> does a user set up a tool to validate an XML document? They can add 
> schemaLocation elements as hints but that is more complex than the 
> separate namespaces. We can produce a single document that includes 
> the others but that couples them together and requires us to version 
> them all together.
>

This is usually specific to the tool. For example with the Eclipse XML 
tools you register your XSD in the Eclipse XML catalog. To validate SCDL 
composites using a set of SCDL extensions, you could just give your tool 
an XSD file including the XSD of the particular extensions. The user 
could write this XSD himself, or we could provide a very simple tool or 
maybe even just a script producing the XSD for him from the selected 
extensions for example. The single namespace approach is definitely 
simpler for users than having them declare so many namespaces, prefixes 
and schemaLocations in all their .composite and .componentType files.

> Secondly, suppose we release kernel and ruby extension using V1.0 of a 
> namespace. We then release V1.1 of the kernel which makes schema 
> changes so we need a new version of its schema, say 1.1; this requires 
> a new V1.1 namespace. How does a user validate the V1.1 kernel XML 
> with V1.0 XML for the ruby extension? The same issue applies as new 
> versions of the ruby or any other extension are produced.

I'm lost, sorry. It would help to go through a real concrete example. 
The Ruby XSD defines a RubyImplementation complex type extending the 
OSOA SCA base Implementation complex type, and an implementation.ruby 
global element with substitutionGroup = "the OSOA SCA 
implementationGroup" . It has no dependencies on another Tuscany kernel 
XSD. I'm actually not sure what you mean by "kernel XML". As far as I 
know there is no "kernel XSD" and I don't see how some "kernel XML" 
would reference a Ruby component. Can you help me understand with a real 
example? Thanks.

>
> The scheme you describe allows users to reuse the same namespace 
> because it does not change the namespace when parts of the schema are 
> released. This means there are multiple definitions of the same 
> localPart in that namespace which is well known as being a real issue.
>
> This is generally understood enough that there was a explicit decision 
> at the Assembly f2f last week (which we both attended) to discourage 
> this redefinition in SCA schemas due to the problems it causes. Heck, 
> we probably spent half the meeting discussing mechanisms to cope with 
> poor schemas that already suffer from this problem - we do not need to 
> make Tuscany's some of those.
>

We spent a lot of time discussing the usage of namespaces in SCA 
applications but we did not change at all to use different namespaces 
for the different SCA specifications. Maybe you are confusing the SCA 
SCDL schema and user schemas used in an SCA application? As far as I 
know, binding and  component implementation type extensions 
(implementation.java, binding.ws, binding.jms,  etc) are still in a 
single namespace, still using a '.' notation to build unique names in 
that single namespace. I think that this is an important characteristic 
of the SCA model, we are trying to avoid an unnecessary proliferation of 
namespaces. I want to keep the same approach in Tuscany: keep the 
programming model simple.

> You state below that coordination is required for multiple namespaces 
> but that simply isn't correct when versioning is done as the 
> references between them are to specific versions. Supporting that is 
> more work for us as implementors as we need to support the multiple 
> versions, but that is our problem and not users'.
>
> -- 
> Jeremy
>
> On Jan 25, 2007, at 5:50 PM, Jean-Sebastien Delfino wrote:
>
>> Jeremy Boynes wrote:
>>> On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote:
>>>>
>>>> The C++ runtime allows bindings and component implementation types 
>>>> to share a common Tuscany namespace and updates to them do not 
>>>> require an update of the Kernel. We simply load the SCDL XSD files 
>>>> out of each runtime extension directory and they can contribute to 
>>>> a common namespace.
>>>>
>>>> As far as I know the Java runtime does not load or make any use of 
>>>> the SCDL XSDs at this point, so I don't understand what the issues 
>>>> would be with the Java runtime.
>>>>
>>>> The bindings and component implementation types defined by the OSOA 
>>>> specs are in a single OSOA namespace. I think that the bindings and 
>>>> component implementation types introduced by the Tuscany project 
>>>> should be in a single Tuscany namespace.
>>>>
>>>> Extensions provided by other projects can be in other namespaces 
>>>> obviously.
>>>
>>> How does this scheme address the versioning issues associated with 
>>> XML namespaces?
>>
>> Could you explain what you mean by this?
>>
>>>
>>> The spec addresses them by coordinating releases from all binding 
>>> and implementation groups.
>>
>> Is that right? I am not aware that all specs sharing the OSOA 
>> namespace are going to be released at the same time. I understand 
>> that the SCA core namespace needs to be released before the 
>> extensions, but I can imagine different extensions being released 
>> independently. If there are dependencies between the various XSDs 
>> (for example a complex type extending another one) their updates 
>> obviously need to coordinated but this would be true with multiple 
>> namespaces as well.
>>
>>> Doing the same in Tuscany would take us back to a model where we 
>>> need to coordinate kernel and all extension releases which is 
>>> something we have decided not to do (for very good reasons).
>>
>> Like I said before I don't think that we need to update the kernel 
>> when extensions change. The Tuscany C++ runtime for example picks up 
>> extension XSDs from extension directories independent of the kernel, 
>> and is able to pick up newer versions of these XSDs without any 
>> change in the kernel. The Java runtime could do the same, but again 
>> at the moment it does not load or make any use of the XSDs anyway...
>>
>> I still don't see any concrete issue at this point.
>>
>>>
>>> --Jeremy
>>>
>>>
>> --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
>
>

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jeremy Boynes <jb...@apache.org>.

There are two concrete issues.

Firstly, with the XSD for the namespace spread over so many files,  
how does a user set up a tool to validate an XML document? They can  
add schemaLocation elements as hints but that is more complex than  
the separate namespaces. We can produce a single document that  
includes the others but that couples them together and requires us to  
version them all together.

Secondly, suppose we release kernel and ruby extension using V1.0 of  
a namespace. We then release V1.1 of the kernel which makes schema  
changes so we need a new version of its schema, say 1.1; this  
requires a new V1.1 namespace. How does a user validate the V1.1  
kernel XML with V1.0 XML for the ruby extension? The same issue  
applies as new versions of the ruby or any other extension are produced.

The scheme you describe allows users to reuse the same namespace  
because it does not change the namespace when parts of the schema are  
released. This means there are multiple definitions of the same  
localPart in that namespace which is well known as being a real issue.

This is generally understood enough that there was a explicit  
decision at the Assembly f2f last week (which we both attended) to  
discourage this redefinition in SCA schemas due to the problems it  
causes. Heck, we probably spent half the meeting discussing  
mechanisms to cope with poor schemas that already suffer from this  
problem - we do not need to make Tuscany's some of those.

You state below that coordination is required for multiple namespaces  
but that simply isn't correct when versioning is done as the  
references between them are to specific versions. Supporting that is  
more work for us as implementors as we need to support the multiple  
versions, but that is our problem and not users'.

--
Jeremy

On Jan 25, 2007, at 5:50 PM, Jean-Sebastien Delfino wrote:

> Jeremy Boynes wrote:
>> On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote:
>>>
>>> The C++ runtime allows bindings and component implementation  
>>> types to share a common Tuscany namespace and updates to them do  
>>> not require an update of the Kernel. We simply load the SCDL XSD  
>>> files out of each runtime extension directory and they can  
>>> contribute to a common namespace.
>>>
>>> As far as I know the Java runtime does not load or make any use  
>>> of the SCDL XSDs at this point, so I don't understand what the  
>>> issues would be with the Java runtime.
>>>
>>> The bindings and component implementation types defined by the  
>>> OSOA specs are in a single OSOA namespace. I think that the  
>>> bindings and component implementation types introduced by the  
>>> Tuscany project should be in a single Tuscany namespace.
>>>
>>> Extensions provided by other projects can be in other namespaces  
>>> obviously.
>>
>> How does this scheme address the versioning issues associated with  
>> XML namespaces?
>
> Could you explain what you mean by this?
>
>>
>> The spec addresses them by coordinating releases from all binding  
>> and implementation groups.
>
> Is that right? I am not aware that all specs sharing the OSOA  
> namespace are going to be released at the same time. I understand  
> that the SCA core namespace needs to be released before the  
> extensions, but I can imagine different extensions being released  
> independently. If there are dependencies between the various XSDs  
> (for example a complex type extending another one) their updates  
> obviously need to coordinated but this would be true with multiple  
> namespaces as well.
>
>> Doing the same in Tuscany would take us back to a model where we  
>> need to coordinate kernel and all extension releases which is  
>> something we have decided not to do (for very good reasons).
>
> Like I said before I don't think that we need to update the kernel  
> when extensions change. The Tuscany C++ runtime for example picks  
> up extension XSDs from extension directories independent of the  
> kernel, and is able to pick up newer versions of these XSDs without  
> any change in the kernel. The Java runtime could do the same, but  
> again at the moment it does not load or make any use of the XSDs  
> anyway...
>
> I still don't see any concrete issue at this point.
>
>>
>> -- 
>> Jeremy
>>
>>
> -- 
> 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: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jean-Sebastien Delfino <js...@apache.org>.

Jeremy Boynes wrote:
> On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote:
>>
>> The C++ runtime allows bindings and component implementation types to 
>> share a common Tuscany namespace and updates to them do not require 
>> an update of the Kernel. We simply load the SCDL XSD files out of 
>> each runtime extension directory and they can contribute to a common 
>> namespace.
>>
>> As far as I know the Java runtime does not load or make any use of 
>> the SCDL XSDs at this point, so I don't understand what the issues 
>> would be with the Java runtime.
>>
>> The bindings and component implementation types defined by the OSOA 
>> specs are in a single OSOA namespace. I think that the bindings and 
>> component implementation types introduced by the Tuscany project 
>> should be in a single Tuscany namespace.
>>
>> Extensions provided by other projects can be in other namespaces 
>> obviously.
>
> How does this scheme address the versioning issues associated with XML 
> namespaces?

Could you explain what you mean by this?

>
> The spec addresses them by coordinating releases from all binding and 
> implementation groups.

Is that right? I am not aware that all specs sharing the OSOA namespace 
are going to be released at the same time. I understand that the SCA 
core namespace needs to be released before the extensions, but I can 
imagine different extensions being released independently. If there are 
dependencies between the various XSDs (for example a complex type 
extending another one) their updates obviously need to coordinated but 
this would be true with multiple namespaces as well.

> Doing the same in Tuscany would take us back to a model where we need 
> to coordinate kernel and all extension releases which is something we 
> have decided not to do (for very good reasons).

Like I said before I don't think that we need to update the kernel when 
extensions change. The Tuscany C++ runtime for example picks up 
extension XSDs from extension directories independent of the kernel, and 
is able to pick up newer versions of these XSDs without any change in 
the kernel. The Java runtime could do the same, but again at the moment 
it does not load or make any use of the XSDs anyway...

I still don't see any concrete issue at this point.

>
> -- 
> Jeremy
>
>
-- 
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jeremy Boynes <jb...@apache.org>.

On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote:
>
> The C++ runtime allows bindings and component implementation types  
> to share a common Tuscany namespace and updates to them do not  
> require an update of the Kernel. We simply load the SCDL XSD files  
> out of each runtime extension directory and they can contribute to  
> a common namespace.
>
> As far as I know the  Java runtime  does not load or make any use  
> of the SCDL XSDs at this point, so I don't understand what the  
> issues would be with the Java runtime.
>
> The bindings and component implementation types defined by the OSOA  
> specs are in a single OSOA namespace. I think that the bindings and  
> component implementation types introduced by the Tuscany project  
> should be in a single Tuscany namespace.
>
> Extensions provided by other projects can be in other namespaces  
> obviously.

How does this scheme address the versioning issues associated with  
XML namespaces?

The spec addresses them by coordinating releases from all binding and  
implementation groups. Doing the same in Tuscany would take us back  
to a model where we need to coordinate kernel and all extension  
releases which is something we have decided not to do (for very good  
reasons).

--
Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jean-Sebastien Delfino <js...@apache.org>.

Jim Marino wrote:
>
> On Jan 24, 2007, at 1:54 AM, ant elder wrote:
>
>> On 1/24/07, Jeremy Boynes <jb...@apache.org> wrote:
>>>
>>> On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote:
>>>
>>> > Jeremy Boynes wrote:
>>> >> -1 on the single namespace as it couples together all the
>>> >> extensions - we would need to create a new version of the
>>> >> namespace every time any extension changed its XML
>>> >
>>> > I prefer a single Tuscany namespace. This is what the OSOA specs
>>> > are doing as well with a single SCA namespace for everything. This
>>> > helps simplfy the programming model as application developers only
>>> > need to declare the single namespace at the top of an SCDL file
>>> > instead of having to list different namespaces for all the
>>> > bindings, implementation types, policies etc. that they use.
>>>
>>> A good goal but how is it achievable in a way that does not require
>>> us to rerelease the schema, the Java and C++ kernels, all extensions
>>> and anything else that references the schema in coordination every
>>> time any one of those makes a schema change? And how do we prevent
>>> changes in one extension impacting users who don't use that extension?
>>>
>>> BTW the OSOA specs do not assume a single namespace and AIUI they
>>> require extensions to be in different ones. There is even discussion
>>> in the spec group about associating user-specific namespaces with all
>>> SCDL definitions.
>>
>>
>> Could you point to where in the specs it talks about requiring 
>> extensions to
>> use different namespaces?
> The spec will not allow "non-spec SCA" extensions to pollute the SCA 
> namespace. For example, any vendor or Tuscany extensions that do not 
> correspond to an SCA specification are not supposed to use the SCA 
> namespace. This should apply to Tuscany as well for extensions not 
> part of the Tuscany project.
>> All the extension spec drafts that I can find are
>> using the single SCA namespace, are these drafts just out of date?
>>
>> I prefer as few namespaces as possible for now as well as it makes 
>> the SCDL
>> so much simpler. How about using the single Tuscany namespace for now 
>> and
>> any extension can change to use some other namespace in the future if
>> required.
>>
> In general I prefer avoiding namespace proliferation but Jeremy raises 
> valid points. Do you have some ideas on how to address those?
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

The C++ runtime allows bindings and component implementation types to 
share a common Tuscany namespace and updates to them do not require an 
update of the Kernel. We simply load the SCDL XSD files out of each 
runtime extension directory and they can contribute to a common namespace.

As far as I know the  Java runtime  does not load or make any use of the 
SCDL XSDs at this point, so I don't understand what the issues would be 
with the Java runtime.

The bindings and component implementation types defined by the OSOA 
specs are in a single OSOA namespace. I think that the bindings and 
component implementation types introduced by the Tuscany project should 
be in a single Tuscany namespace.

Extensions provided by other projects can be in other namespaces obviously.

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jim Marino <jm...@myromatours.com>.

On Jan 24, 2007, at 1:54 AM, ant elder wrote:

> On 1/24/07, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote:
>>
>> > Jeremy Boynes wrote:
>> >> -1 on the single namespace as it couples together all the
>> >> extensions - we would need to create a new version of the
>> >> namespace every time any extension changed its XML
>> >
>> > I prefer a single Tuscany namespace. This is what the OSOA specs
>> > are doing as well with a single SCA namespace for everything. This
>> > helps simplfy the programming model as application developers only
>> > need to declare the single namespace at the top of an SCDL file
>> > instead of having to list different namespaces for all the
>> > bindings, implementation types, policies etc. that they use.
>>
>> A good goal but how is it achievable in a way that does not require
>> us to rerelease the schema, the Java and C++ kernels, all extensions
>> and anything else that references the schema in coordination every
>> time any one of those makes a schema change? And how do we prevent
>> changes in one extension impacting users who don't use that  
>> extension?
>>
>> BTW the OSOA specs do not assume a single namespace and AIUI they
>> require extensions to be in different ones. There is even discussion
>> in the spec group about associating user-specific namespaces with all
>> SCDL definitions.
>
>
> Could you point to where in the specs it talks about requiring  
> extensions to
> use different namespaces?
The spec will not allow "non-spec SCA" extensions to pollute the SCA  
namespace. For example, any vendor or Tuscany extensions that do not  
correspond to an SCA specification are not supposed to use the SCA  
namespace. This should apply to Tuscany as well for extensions not  
part of the Tuscany project.
> All the extension spec drafts that I can find are
> using the single SCA namespace, are these drafts just out of date?
>
> I prefer as few namespaces as possible for now as well as it makes  
> the SCDL
> so much simpler. How about using the single Tuscany namespace for  
> now and
> any extension can change to use some other namespace in the future if
> required.
>
In general I prefer avoiding namespace proliferation but Jeremy  
raises valid points. Do you have some ideas on how to address those?

Jim


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jeremy Boynes <jb...@apache.org>.

On Jan 24, 2007, at 5:30 AM, Rick wrote:

> Hello,
> Not XML schema guru but in the assembly spec don't extension fall  
> in XML schemas given under <any namespace="##other" ...   and the  
> "##other" imply a namespace other than the sca one ?
>

Yes, that's what I was referring to.
Also <implementation> and <binding> etc. all use substitution groups  
to allow non-blessed versions from different namespaces.

This was specifically done by the spec to allow vendors implementing  
it to release proprietary extensions independently. We need to do the  
same with Tuscany extensions so that they too can be released  
independently.

--
Jeremy

> ant elder wrote:
>> On 1/24/07, Jeremy Boynes <jb...@apache.org> wrote:
>>>
>>> On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote:
>>>
>>> > Jeremy Boynes wrote:
>>> >> -1 on the single namespace as it couples together all the
>>> >> extensions - we would need to create a new version of the
>>> >> namespace every time any extension changed its XML
>>> >
>>> > I prefer a single Tuscany namespace. This is what the OSOA specs
>>> > are doing as well with a single SCA namespace for everything. This
>>> > helps simplfy the programming model as application developers only
>>> > need to declare the single namespace at the top of an SCDL file
>>> > instead of having to list different namespaces for all the
>>> > bindings, implementation types, policies etc. that they use.
>>>
>>> A good goal but how is it achievable in a way that does not require
>>> us to rerelease the schema, the Java and C++ kernels, all extensions
>>> and anything else that references the schema in coordination every
>>> time any one of those makes a schema change? And how do we prevent
>>> changes in one extension impacting users who don't use that  
>>> extension?
>>>
>>> BTW the OSOA specs do not assume a single namespace and AIUI they
>>> require extensions to be in different ones. There is even discussion
>>> in the spec group about associating user-specific namespaces with  
>>> all
>>> SCDL definitions.
>> Could you point to where in the specs it talks about requiring  
>> extensions to
>> use different namespaces? All the extension spec drafts that I can  
>> find are
>> using the single SCA namespace, are these drafts just out of date?
>> I prefer as few namespaces as possible for now as well as it makes  
>> the SCDL
>> so much simpler. How about using the single Tuscany namespace for  
>> now and
>> any extension can change to use some other namespace in the future if
>> required.
>>   ...ant
>
> ---------------------------------------------------------------------
> 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: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Rick <cr...@gmail.com>.

Hello,
Not XML schema guru but in the assembly spec don't extension fall in XML schemas 
given under <any namespace="##other" ...   and the "##other" imply a namespace 
other than the sca one ?

ant elder wrote:
> On 1/24/07, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote:
>>
>> > Jeremy Boynes wrote:
>> >> -1 on the single namespace as it couples together all the
>> >> extensions - we would need to create a new version of the
>> >> namespace every time any extension changed its XML
>> >
>> > I prefer a single Tuscany namespace. This is what the OSOA specs
>> > are doing as well with a single SCA namespace for everything. This
>> > helps simplfy the programming model as application developers only
>> > need to declare the single namespace at the top of an SCDL file
>> > instead of having to list different namespaces for all the
>> > bindings, implementation types, policies etc. that they use.
>>
>> A good goal but how is it achievable in a way that does not require
>> us to rerelease the schema, the Java and C++ kernels, all extensions
>> and anything else that references the schema in coordination every
>> time any one of those makes a schema change? And how do we prevent
>> changes in one extension impacting users who don't use that extension?
>>
>> BTW the OSOA specs do not assume a single namespace and AIUI they
>> require extensions to be in different ones. There is even discussion
>> in the spec group about associating user-specific namespaces with all
>> SCDL definitions.
> 
> 
> Could you point to where in the specs it talks about requiring 
> extensions to
> use different namespaces? All the extension spec drafts that I can find are
> using the single SCA namespace, are these drafts just out of date?
> 
> I prefer as few namespaces as possible for now as well as it makes the SCDL
> so much simpler. How about using the single Tuscany namespace for now and
> any extension can change to use some other namespace in the future if
> required.
> 
>   ...ant
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by ant elder <an...@gmail.com>.

On 1/24/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote:
>
> > Jeremy Boynes wrote:
> >> -1 on the single namespace as it couples together all the
> >> extensions - we would need to create a new version of the
> >> namespace every time any extension changed its XML
> >
> > I prefer a single Tuscany namespace. This is what the OSOA specs
> > are doing as well with a single SCA namespace for everything. This
> > helps simplfy the programming model as application developers only
> > need to declare the single namespace at the top of an SCDL file
> > instead of having to list different namespaces for all the
> > bindings, implementation types, policies etc. that they use.
>
> A good goal but how is it achievable in a way that does not require
> us to rerelease the schema, the Java and C++ kernels, all extensions
> and anything else that references the schema in coordination every
> time any one of those makes a schema change? And how do we prevent
> changes in one extension impacting users who don't use that extension?
>
> BTW the OSOA specs do not assume a single namespace and AIUI they
> require extensions to be in different ones. There is even discussion
> in the spec group about associating user-specific namespaces with all
> SCDL definitions.


Could you point to where in the specs it talks about requiring extensions to
use different namespaces? All the extension spec drafts that I can find are
using the single SCA namespace, are these drafts just out of date?

I prefer as few namespaces as possible for now as well as it makes the SCDL
so much simpler. How about using the single Tuscany namespace for now and
any extension can change to use some other namespace in the future if
required.

   ...ant

Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jeremy Boynes <jb...@apache.org>.

On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote:

> Jeremy Boynes wrote:
>> -1 on the single namespace as it couples together all the  
>> extensions - we would need to create a new version of the  
>> namespace every time any extension changed its XML
>
> I prefer a single Tuscany namespace. This is what the OSOA specs  
> are doing as well with a single SCA namespace for everything. This  
> helps simplfy the programming model as application developers only  
> need to declare the single namespace at the top of an SCDL file  
> instead of having to list different namespaces for all the  
> bindings, implementation types, policies etc. that they use.

A good goal but how is it achievable in a way that does not require  
us to rerelease the schema, the Java and C++ kernels, all extensions  
and anything else that references the schema in coordination every  
time any one of those makes a schema change? And how do we prevent  
changes in one extension impacting users who don't use that extension?

BTW the OSOA specs do not assume a single namespace and AIUI they  
require extensions to be in different ones. There is even discussion  
in the spec group about associating user-specific namespaces with all  
SCDL definitions.

--
Jeremy

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jean-Sebastien Delfino <js...@apache.org>.

Jeremy Boynes wrote:
> -1 on the single namespace as it couples together all the extensions - 
> we would need to create a new version of the namespace every time any 
> extension changed its XML
>
> -- 
> Jeremy
>
> On Jan 23, 2007, at 4:35 AM, ant elder (JIRA) wrote:
>
>>
>>      [ 
>> https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
>> ]
>>
>> ant elder reassigned TUSCANY-1053:
>> ----------------------------------
>>
>>     Assignee: ant elder
>>
>>> Use a Tuscany namespace for all non-spec'd Tuscany extensions
>>> -------------------------------------------------------------
>>>
>>>                 Key: TUSCANY-1053
>>>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1053
>>>             Project: Tuscany
>>>          Issue Type: Improvement
>>>    Affects Versions: Java-M2
>>>            Reporter: ant elder
>>>         Assigned To: ant elder
>>>             Fix For: Java-SCA-M3
>>>
>>>
>>> Currently Tsucany extensions use SCDL elements is varrious different 
>>> namespaces. There should be a single Tuscany namespace that 
>>> extensions not defined by SCA spec's should use. See 
>>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e 
>>>
>>
>> --This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>

I prefer a single Tuscany namespace. This is what the OSOA specs are 
doing as well with a single SCA namespace for everything. This helps 
simplfy the programming model as application developers only need to 
declare the single namespace at the top of an SCDL file instead of 
having to list different namespaces for all the bindings, implementation 
types, policies etc. that they use.

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by Jeremy Boynes <jb...@apache.org>.

-1 on the single namespace as it couples together all the extensions  
- we would need to create a new version of the namespace every time  
any extension changed its XML

--
Jeremy

On Jan 23, 2007, at 4:35 AM, ant elder (JIRA) wrote:

>
>      [ https://issues.apache.org/jira/browse/TUSCANY-1053? 
> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> ant elder reassigned TUSCANY-1053:
> ----------------------------------
>
>     Assignee: ant elder
>
>> Use a Tuscany namespace for all non-spec'd Tuscany extensions
>> -------------------------------------------------------------
>>
>>                 Key: TUSCANY-1053
>>                 URL: https://issues.apache.org/jira/browse/ 
>> TUSCANY-1053
>>             Project: Tuscany
>>          Issue Type: Improvement
>>    Affects Versions: Java-M2
>>            Reporter: ant elder
>>         Assigned To: ant elder
>>             Fix For: Java-SCA-M3
>>
>>
>> Currently Tsucany extensions use SCDL elements is varrious  
>> different namespaces. There should be a single Tuscany namespace  
>> that extensions not defined by SCA spec's should use. See http:// 
>> mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/% 
>> 3c45A27466.20504@apache.org%3e
>
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> 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

[jira] Assigned: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions

Posted by "ant elder (JIRA)" <tu...@ws.apache.org>.

     [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ant elder reassigned TUSCANY-1053:
----------------------------------

    Assignee: ant elder

> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> -------------------------------------------------------------
>
>                 Key: TUSCANY-1053
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1053
>             Project: Tuscany
>          Issue Type: Improvement
>    Affects Versions: Java-M2
>            Reporter: ant elder
>         Assigned To: ant elder
>             Fix For: Java-SCA-M3
>
>
> Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org