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]
