[SDO C++] JIRA Issues: Specification or Implementation concerns?

[Mike Edwards <mi...@gmail.com>]

Folks,

I notice a number of JIRA issues raised against the SDO C++ 
implementation that have the smell of being specification issues rather 
than implementation issues.

If the issues really do imply changing or extending the specification of 
SDO for C++, then I believe that the issues should rightly be raised 
against the specification itself (the spec group have their own 
infrastructure and email lists).

I'm OK with having "tracker" issues raised in the Tuscany project which 
point to issues raised with the specs, but it must be clear that any 
changes to the specs must ultimately be made by the specification teams.


Yours,  Mike.

Re: [SDO C++] JIRA Issues: Specification or Implementation concerns?

[Pete Robbins <ro...@googlemail.com>]

I'm not sure where the SDO spec is being discussed. It is separate from the
C++ C&I group.

On 09/03/06, Mike Edwards <mi...@gmail.com> wrote:
>
> Ant,
>
> At the moment, neither the SDO nor the SCA specification lists are
> publicly viewable.
>
> For SCA, we are investigating setting up a public website - one function
> of this website would be to allow for publicly viewable lists.
>
> Yours,  Mike.
>
> ant elder wrote:
> > On 3/9/06, Mike Edwards <mi...@gmail.com> wrote:
> > <snip>
> >
> >  (the spec group have their own
> >
> >>infrastructure and email lists).
> >>
> >>
> >
> > I remember a post from months ago saying these lists were going to be
> made
> > publicly viewable, has that ever happened, is there an archive I can
> look
> > at?
> >
> >    ...ant
> >
>

Re: [SDO C++] JIRA Issues: Specification or Implementation concerns?

[Mike Edwards <mi...@gmail.com>]

Ant,

At the moment, neither the SDO nor the SCA specification lists are 
publicly viewable.

For SCA, we are investigating setting up a public website - one function
of this website would be to allow for publicly viewable lists.

Yours,  Mike.

ant elder wrote:
> On 3/9/06, Mike Edwards <mi...@gmail.com> wrote:
> <snip>
> 
>  (the spec group have their own
> 
>>infrastructure and email lists).
>>
>>
> 
> I remember a post from months ago saying these lists were going to be made
> publicly viewable, has that ever happened, is there an archive I can look
> at?
> 
>    ...ant
> 

Re: [SDO C++] JIRA Issues: Specification or Implementation concerns?

[ant elder <an...@gmail.com>]

On 3/9/06, Mike Edwards <mi...@gmail.com> wrote:
<snip>

 (the spec group have their own
> infrastructure and email lists).
>
>
I remember a post from months ago saying these lists were going to be made
publicly viewable, has that ever happened, is there an archive I can look
at?

   ...ant

Re: [SDO C++] JIRA Issues: Specification or Implementation concerns?

[Edward Slattery <ed...@googlemail.com>]

I think I raised all the issues against SDO C++. The purpose of them is to
track the current differences between what is specified and what is
implemented, with the aim of making the implementation of the C++ SDO closer
to the C++ specification, and if possible and desirable, making the C++
interface closer to the java specification.
None of the issues raised are intended to imply a change of the
specification to closer reflect the implementation. If in implementing the
code, a divergeance from the spec seems useful, it will be raised as a
concern on the SDO spec group.


On 09/03/06, Mike Edwards <mi...@gmail.com> wrote:
>
> Folks,
>
> I notice a number of JIRA issues raised against the SDO C++
> implementation that have the smell of being specification issues rather
> than implementation issues.
>
> If the issues really do imply changing or extending the specification of
> SDO for C++, then I believe that the issues should rightly be raised
> against the specification itself (the spec group have their own
> infrastructure and email lists).
>
> I'm OK with having "tracker" issues raised in the Tuscany project which
> point to issues raised with the specs, but it must be clear that any
> changes to the specs must ultimately be made by the specification teams.
>
>
> Yours,  Mike.
>