On 8/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> 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
