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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
