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 <[EMAIL PROTECTED]> wrote:

I have reopened the JIRA and will give it a try...

On 8/2/07, Mike Edwards <[EMAIL PROTECTED]> 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/[EMAIL 
PROTECTED]

---------------------------------------------------------------------
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]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to