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/07/31 18:08:53 UTC
[jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all
non-spec'd Tuscany extensions
[ 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
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