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/[EMAIL
PROTECTED]
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
