Done under revision #568830
On 8/22/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
> Jean-Sebastien,
>
> Jean-Sebastien Delfino wrote:
>
> >
> > Looks like option (B) is the most preferred option with:
> > - one -1
> > - five +1
> > - one "more spec compliant"
> >
> > Do we need more technical discu
Jean-Sebastien,
Jean-Sebastien Delfino wrote:
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?
Thanks for a great summary.
I'm happy with the conclusi
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]> wro
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
-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
handl
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 n
Ok sure eventually why not. But I don't think we should wait till that
happens before doing [a].
...ant
On 8/20/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi Ant, just to understand a little better - do you propose we must get
> our extensions endorsed by the Specs ?
>
> - Venkat
>
>
Hi Ant, just to understand a little better - do you propose we must get our
extensions endorsed by the Specs ?
- Venkat
On 8/20/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> On 8/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> > Luciano Resende wrote:
> > > Sebastien wrote :
> > >
>
+1 for option [B] alone. Given the fact that we are going to rely more on
tooling to define composites this shouldn't be a problem.
- Venkat
On 8/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Luciano Resende wrote:
> > Sebastien wrote :
> >
> >> IMO application developers shouldn'
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?
> >>
> >
he repeating prefixes.
>
> B) is right usage of XML namespaces.
>
> Hopefully, the SCA tooling can help ease the XML namespace declarations.
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
>
, 2007 5:07 PM
Subject: Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all
non-spec'd Tuscany extensions
Luciano Resende wrote:
Sebastien wrote :
IMO application developers shouldn't have to suffer from the
complexity of XML...
How about supporting composites w
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
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
ant elder wrote:
The last comments have been in favour of keeping things as-is so how about
just doing nothing and letting this thread die.
...ant
Here are the last comments from the different people who contributed to
this thread:
- Mike, http://www.mail-archive.com/tuscany-dev@ws.ap
The last comments have been in favour of keeping things as-is so how about
just doing nothing and letting this thread die.
...ant
On 8/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> ant elder wrote:
> > On 8/3/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> >> ant eld
ant elder wrote:
On 8/3/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
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
On 8/3/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> 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 qui
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/0
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 <[EMA
Wouldn't this cause breakage in the scenario that I described, where
from Tuscany later turns into as part of SCA but with some
differences? Any SCDLs written to just use plain would break
when Tuscany steps up to support the SCA .
Simon
ant elder wrote:
How about having the Tuscany name
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 woul
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 qui
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 p
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. I
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) wro
If I understand this comment correctly, this is a spec violation that
needs to be fixed. From the assembly 1.0 spec:
2535 schemas. New interface types, implementation types and binding types that
are defined using
2536 this extensibility model, which are not part of these SCA specifications
mu
[
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 Tus
28 matches
Mail list logo
