You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2006/12/01 15:40:06 UTC
[C++] Who is working on which SDO problems
I have been chatting with the PHP SCA team about their various SDO problems
and I would be interested to know who is working on what so I look at things
in transit. I'm particularly interested in the following problems:
http://issues.apache.org/jira/browse/TUSCANY-960 - Spurious
xsi:type="OpenDataObject" attribute generated
http://issues.apache.org/jira/browse/TUSCANY-950 - Copy helper forgets
sequence information
(not sure which bug - i seem to remember a post about it) - Attributes
repeated as elements on output
http://issues.apache.org/jira/browse/TUSCANY-873 - I'm going to open this
one up again if I can as it's got a bit missing w.r.t copying open content.
But of course it would be worth noting anything else that's going on at the
moment that might have an impact on copying problems
Regards
Simon
Re: [C++] Who is working on which SDO problems
Posted by Yang ZHONG <le...@gmail.com>.
The prototype has been attached into
http://issues.apache.org/jira/browse/TUSCANY-990
On 12/12/06, Yang ZHONG <le...@gmail.com> wrote:
>
> It's also discussed in another thread:
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
>
> I've prototyped and will create a JIRA to attach.
>
>
> On 12/12/06, Caroline Maynard <ca...@gmail.com> wrote:
> >
> > There's a lot of hard work gone into fixing all the problems we're
> > seeing
> > with sequenced and open types, which is much appreciated. Can we now
> > discuss
> > another set of problems we're seeing with the schema support, concerned
> > with
> > performance issues? Although you may not want to do much detailed work
> > on
> > performance at this stage, with a newish project like Tuscany, there are
> >
> > likely to be some "low-hanging fruit" which could make a lot of
> > difference
> > if picked off.
> >
> > Performance seems fine with simple schema, but more complex schema such
> > as
> > Atom are taking a surprisingly long time to load. Some of the reasons
> > are
> > apparently:
> >
> > - cyclic dependencies within the schema cause recursive type-checking.
> >
> > - schemas are loaded too many times. I think this is a problem
> > exclusively in the way our code uses Tuscany, but I'll add it to this
> > list
> > in case you think Tuscany may be contributing to it too.
> > - schemas once loaded are not cached.
> > - Tuscany looks in too many places to find the schema, for example
> > http://issues.apache.org/jira/browse/TUSCANY-907. I realise the spec
> > is quite open in the area of how to interpret the schemaLocation value
> > and
> > what to do if it is missing, and perhaps some configuration options
> > are
> > needed here.
> >
> >
>
>
> --
>
> Yang ZHONG
--
Yang ZHONG
Re: [C++] Who is working on which SDO problems
Posted by Yang ZHONG <le...@gmail.com>.
It's also discussed in another thread:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg11793.html
I've prototyped and will create a JIRA to attach.
On 12/12/06, Caroline Maynard <ca...@gmail.com> wrote:
>
> There's a lot of hard work gone into fixing all the problems we're seeing
> with sequenced and open types, which is much appreciated. Can we now
> discuss
> another set of problems we're seeing with the schema support, concerned
> with
> performance issues? Although you may not want to do much detailed work on
> performance at this stage, with a newish project like Tuscany, there are
> likely to be some "low-hanging fruit" which could make a lot of difference
> if picked off.
>
> Performance seems fine with simple schema, but more complex schema such as
> Atom are taking a surprisingly long time to load. Some of the reasons are
> apparently:
>
> - cyclic dependencies within the schema cause recursive type-checking.
>
> - schemas are loaded too many times. I think this is a problem
> exclusively in the way our code uses Tuscany, but I'll add it to this
> list
> in case you think Tuscany may be contributing to it too.
> - schemas once loaded are not cached.
> - Tuscany looks in too many places to find the schema, for example
> http://issues.apache.org/jira/browse/TUSCANY-907. I realise the spec
> is quite open in the area of how to interpret the schemaLocation value
> and
> what to do if it is missing, and perhaps some configuration options are
> needed here.
>
>
--
Yang ZHONG
Re: [C++] Who is working on which SDO problems
Posted by Caroline Maynard <ca...@gmail.com>.
There's a lot of hard work gone into fixing all the problems we're seeing
with sequenced and open types, which is much appreciated. Can we now discuss
another set of problems we're seeing with the schema support, concerned with
performance issues? Although you may not want to do much detailed work on
performance at this stage, with a newish project like Tuscany, there are
likely to be some "low-hanging fruit" which could make a lot of difference
if picked off.
Performance seems fine with simple schema, but more complex schema such as
Atom are taking a surprisingly long time to load. Some of the reasons are
apparently:
- cyclic dependencies within the schema cause recursive type-checking.
- schemas are loaded too many times. I think this is a problem
exclusively in the way our code uses Tuscany, but I'll add it to this list
in case you think Tuscany may be contributing to it too.
- schemas once loaded are not cached.
- Tuscany looks in too many places to find the schema, for example
http://issues.apache.org/jira/browse/TUSCANY-907. I realise the spec
is quite open in the area of how to interpret the schemaLocation value and
what to do if it is missing, and perhaps some configuration options are
needed here.
Re: [C++] Who is working on which SDO problems
Posted by Simon Laws <si...@googlemail.com>.
On 12/1/06, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 12/1/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> >
> > On 01/12/06, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > I have been chatting with the PHP SCA team about their various SDO
> > > problems
> > > and I would be interested to know who is working on what so I look at
> > > things
> > > in transit. I'm particularly interested in the following problems:
> > >
> > > http://issues.apache.org/jira/browse/TUSCANY-960 - Spurious
> > > xsi:type="OpenDataObject" attribute generated
> > > http://issues.apache.org/jira/browse/TUSCANY-950 - Copy helper forgets
> > > sequence information
> > > (not sure which bug - i seem to remember a post about it) - Attributes
> > > repeated as elements on output
> > > http://issues.apache.org/jira/browse/TUSCANY-873 - I'm going to open
> > this
> > > one up again if I can as it's got a bit missing w.r.t copying open
> > > content.
> > >
> > > But of course it would be worth noting anything else that's going on
> > at
> > > the
> > > moment that might have an impact on copying problems
> > >
> > > Regards
> > >
> > > Simon
> > >
> > >
> > I'll be on vacation for the first three days of next week, but when I
> > get
> > back I'll take a look at whichever ones need attention.
> >
> > Regards,
> >
> > Geoff.
>
>
> Great, thx Geoff. Have a good time. I pinged Caroline off line and she is
> working with Pete on a WSDL problem so I think the answer is that no one is
> currently working on any of these. I have created a fix to make copying work
> properly when there are many valued types in the DO (a feature of open
> types). I'll attach this to a 873 shortly as this is an extension of the
> existing fix. I'll now have a crack at 950.
>
> Simon
>
>
>
Sorry for another mail on this but I should of course say that if anyone
wants to lend a hand in any of this then come on it the waters lovely. This
is in an effort to allow the people working on PHP SCA to make progress.
Simon
Reg
Re: [C++] Fix to TUSCANY-963, was: Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
On 04/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Pete Robbins wrote:
> > Simon, I have also ben looking at a fix for 950 and although it is
> fairly
> > straightforward to fix the case in the Jira it gets rather complicated
> > when
> > you consider properties that are not intended to be part of the
> > sequence (
> > e.g. attributes but could be element properties that have been set
> > without
> > using the sequence API).
> >
> > On 03/12/06, Simon Laws <si...@googlemail.com> wrote:
> >>
> >> On 12/3/06, Simon Laws <si...@googlemail.com> wrote:
> >> >
> >> > I've been working on a fix for 950 which I managed to complete so
> that
> >> you
> >> > could successfully copy a DO tree containing both mixed and open
> >> types.
> >> I
> >> > then applied your fix for 963 and the resulting SDO fails. It happily
> >> does
> >> > the copy still but won't print out elements in sequences or open
> typed
> >> > elements from the new DO that results from the copy.
> >> >
> >
> >
> > ... and this is exactly one of the issues I ran up against!!
> >
> >> Looking at the svn commit for 963 the main change seems to be to the
> >> > SDOXMLWriter.
> >> >
> >> > // Do not write attributes as members of the
> >> > sequence
> >> > XSDPropertyInfo* pi =
> >> getPropertyInfo(seqPropType,
> >> > seqProp);
> >> > PropertyDefinitionImpl propdef;
> >> > if (!pi ||
> >> > (pi->getPropertyDefinition().isElement))
> >> > {
> >> > continue;
> >> > }
> >> >
> >> > I'm not au fait with how property info works but taking a tour
> >> round the
> >> > code it seems to be where the DAS keeps extra info derived from the
> >> schema
> >> > that is only used when writing back out to XML. The change finds,
> from
> >> the
> >> > property info, those elements that are really attributes and hence
> >> only
> >> > writes them as attributes.
> >> >
> >> > 1/ The first thing that looks a little fishy is "if (!pi ||
> >> > (pi->getPropertyDefinition().isElement))" which looks like it
> >> breaks out
> >> of
> >> > the loop if the property represents an element rather than when
> >> it's not
> >> an
> >> > element. Is this right?
> >> >
> >
> >
> > A better test here would be "have we already written this property as an
> > attribute". The intent here is to only write properties that are
> > explicitly
> > defined as elements.
> >
> >> Regardless of the correctness of this my copy doesn't work because
> "!pi"
> >> > is always true after I have copied the sequence. Can you explain to
> me
> >> how
> >> > property information is intended to work. I need to know if I should
> >> copy
> >> > anything more than just the instance information. I had thought
> >> everything
> >> > else was in the model and hence I don't need to copy it.
> >> >
> >
> >
> > The PropertyInformation is basically a collection of information we
> > remember
> > from the schema to enable us to serialize it as a schema intended. I
> > believe
> > we were going to add the ability to add this information
> programmatically
> > and this may even have made it into the spec... I need to check.
> >
> >
> >> With the schema:
> >> >
> >> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> >> > xmlns:tns="http://www.example.org/test "
> >> > targetNamespace="http://www.example.org/test">
> >> >
> >> > <complexType name="CloneType" mixed="true">
> >> > <sequence>
> >> > <element name="test" type="string"/>
> >> > <any namespace="##any"/>
> >> > </sequence>
> >> > </complexType>
> >> >
> >> > <element name="Clone" type="tns:CloneType"/>
> >> >
> >> > </schema>
> >> >
> >> > And the XML document:
> >> >
> >> > <Clone xmlns="http://www.example.org/test"
> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> >> > xsi:schemaLocation="http://www.example.org/test
> >> clone.xsd ">
> >> > abc
> >> > <test>test</test>
> >> > def
> >> > <tests>test</tests>
> >> > ghi
> >> > </Clone>
> >> >
> >> > CloneType does have property info associated with it. But neither
> >> > commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject
> >> (the
> >> > type of tests) have property info associated with them once the
> schema
> >> has
> >> > been read. Hence it is not present in the model after the copy and
> the
> >> new
> >> > writer doesn't write out "test" or "tests".
> >
> >
> > Types never have PropertyInformation on them... nor will ANY open
> > property
> > as these, by definition, are not defined by a schema. So this is where
> my
> > "fix" for 963 fails as your test and tests properties will never have
> > any pi
> > associated with them.
> >
> > My changes (so far) are attached to
> >> http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them
> but
> >> also as a backup.
> >
> >
> >
> > I'll take a look and see how close these are to my intended fix ;-)
> >
> > I'll also go back and revisit the 963 fix to cope with open types.
> >
> >
> >
> > Cheers,
> >
>
> I think that the change to fix TUSCANY-963 also broke the HttpdBigBank
> scenario. After some debugging it looks like elements under an open type
> are not written anymore. What's strange is that they seem to be written
> in some cases and not in some other cases. I am not completely sure
> since the HttpdBigBank scenario is a little complex and only some of the
> exchanges fail but it looks like simple elements are written and complex
> type elements are not... again I'm not sure... Anyway, if I revert back
> to revision r980964 of SDOWriter.cpp it works, with the head revision it
> doesn't.
Correct. Fix is a bad un as it doen't handle open content. Hope to fix that
today
--
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Pete
[C++] Fix to TUSCANY-963, was: Who is working on which SDO problems
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> Simon, I have also ben looking at a fix for 950 and although it is fairly
> straightforward to fix the case in the Jira it gets rather complicated
> when
> you consider properties that are not intended to be part of the
> sequence (
> e.g. attributes but could be element properties that have been set
> without
> using the sequence API).
>
> On 03/12/06, Simon Laws <si...@googlemail.com> wrote:
>>
>> On 12/3/06, Simon Laws <si...@googlemail.com> wrote:
>> >
>> > I've been working on a fix for 950 which I managed to complete so that
>> you
>> > could successfully copy a DO tree containing both mixed and open
>> types.
>> I
>> > then applied your fix for 963 and the resulting SDO fails. It happily
>> does
>> > the copy still but won't print out elements in sequences or open typed
>> > elements from the new DO that results from the copy.
>> >
>
>
> ... and this is exactly one of the issues I ran up against!!
>
>> Looking at the svn commit for 963 the main change seems to be to the
>> > SDOXMLWriter.
>> >
>> > // Do not write attributes as members of the
>> > sequence
>> > XSDPropertyInfo* pi =
>> getPropertyInfo(seqPropType,
>> > seqProp);
>> > PropertyDefinitionImpl propdef;
>> > if (!pi ||
>> > (pi->getPropertyDefinition().isElement))
>> > {
>> > continue;
>> > }
>> >
>> > I'm not au fait with how property info works but taking a tour
>> round the
>> > code it seems to be where the DAS keeps extra info derived from the
>> schema
>> > that is only used when writing back out to XML. The change finds, from
>> the
>> > property info, those elements that are really attributes and hence
>> only
>> > writes them as attributes.
>> >
>> > 1/ The first thing that looks a little fishy is "if (!pi ||
>> > (pi->getPropertyDefinition().isElement))" which looks like it
>> breaks out
>> of
>> > the loop if the property represents an element rather than when
>> it's not
>> an
>> > element. Is this right?
>> >
>
>
> A better test here would be "have we already written this property as an
> attribute". The intent here is to only write properties that are
> explicitly
> defined as elements.
>
>> Regardless of the correctness of this my copy doesn't work because "!pi"
>> > is always true after I have copied the sequence. Can you explain to me
>> how
>> > property information is intended to work. I need to know if I should
>> copy
>> > anything more than just the instance information. I had thought
>> everything
>> > else was in the model and hence I don't need to copy it.
>> >
>
>
> The PropertyInformation is basically a collection of information we
> remember
> from the schema to enable us to serialize it as a schema intended. I
> believe
> we were going to add the ability to add this information programmatically
> and this may even have made it into the spec... I need to check.
>
>
>> With the schema:
>> >
>> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
>> > xmlns:tns="http://www.example.org/test "
>> > targetNamespace="http://www.example.org/test">
>> >
>> > <complexType name="CloneType" mixed="true">
>> > <sequence>
>> > <element name="test" type="string"/>
>> > <any namespace="##any"/>
>> > </sequence>
>> > </complexType>
>> >
>> > <element name="Clone" type="tns:CloneType"/>
>> >
>> > </schema>
>> >
>> > And the XML document:
>> >
>> > <Clone xmlns="http://www.example.org/test"
>> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
>> > xsi:schemaLocation="http://www.example.org/test
>> clone.xsd ">
>> > abc
>> > <test>test</test>
>> > def
>> > <tests>test</tests>
>> > ghi
>> > </Clone>
>> >
>> > CloneType does have property info associated with it. But neither
>> > commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject
>> (the
>> > type of tests) have property info associated with them once the schema
>> has
>> > been read. Hence it is not present in the model after the copy and the
>> new
>> > writer doesn't write out "test" or "tests".
>
>
> Types never have PropertyInformation on them... nor will ANY open
> property
> as these, by definition, are not defined by a schema. So this is where my
> "fix" for 963 fails as your test and tests properties will never have
> any pi
> associated with them.
>
> My changes (so far) are attached to
>> http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them but
>> also as a backup.
>
>
>
> I'll take a look and see how close these are to my intended fix ;-)
>
> I'll also go back and revisit the 963 fix to cope with open types.
>
>
>
> Cheers,
>
I think that the change to fix TUSCANY-963 also broke the HttpdBigBank
scenario. After some debugging it looks like elements under an open type
are not written anymore. What's strange is that they seem to be written
in some cases and not in some other cases. I am not completely sure
since the HttpdBigBank scenario is a little complex and only some of the
exchanges fail but it looks like simple elements are written and complex
type elements are not... again I'm not sure... Anyway, if I revert back
to revision r980964 of SDOWriter.cpp it works, with the head revision it
doesn't.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
Thanks Yang. I'm going to have a trawl throught the Jiras and prioritise.
There are some I know about that I haven't raised yet that could be quite
large pieces of work, for instance there seems to be a performance issue
loading large schema which contain lots of ref="..." elements. I'll post a
first take on what I think are the major issues so we can discuss here.
Hopefully I can do that tomorrow.
Cheers,
On 06/12/06, Yang ZHONG <le...@gmail.com> wrote:
>
> I'd like to help, so which other SDO defects are holding folk up?
>
> On 12/5/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> > I have just checked in a new fix for 963.
> >
> > Which other SDO defects are holfing folk up?
> >
> > Cheers,
> >
> > --
> > Pete
> >
> >
>
>
> --
>
> Yang ZHONG
>
>
--
Pete
Re: [C++] Who is working on which SDO problems
Posted by Yang ZHONG <le...@gmail.com>.
I'd like to help, so which other SDO defects are holding folk up?
On 12/5/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> I have just checked in a new fix for 963.
>
> Which other SDO defects are holfing folk up?
>
> Cheers,
>
> --
> Pete
>
>
--
Yang ZHONG
Re: [C++] Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
On 08/12/06, Yang ZHONG <le...@gmail.com> wrote:
>
> I'm working on 907, 959 and 450.
>
> --
>
> Yang ZHONG
>
>
great. Post here if you have any problems.
Cheers,
--
Pete
Re: [C++] Who is working on which SDO problems
Posted by Yang ZHONG <le...@gmail.com>.
I'm working on 907, 959 and 450.
--
Yang ZHONG
Re: [C++] Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
On 07/12/06, Caroline Maynard <ca...@gmail.com> wrote:
>
> On 05/12/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> >
> > Which other SDO defects are holfing folk up?
>
>
> I just created http://issues.apache.org/jira/browse/TUSCANY-980. This is
> closely related to many of the issues discussed on this thread, but I
> don't
> think it's a dup.
>
>
Thanks for that. A nice description of the problem. I have checked in a fix
for the first part and will look into the 2nd problem using Sequence.
Cheers,
--
Pete
Re: [C++] Who is working on which SDO problems
Posted by Caroline Maynard <ca...@gmail.com>.
On 05/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>
>
> Which other SDO defects are holfing folk up?
I just created http://issues.apache.org/jira/browse/TUSCANY-980. This is
closely related to many of the issues discussed on this thread, but I don't
think it's a dup.
Re: [C++] Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
I have just checked in a new fix for 963.
Which other SDO defects are holfing folk up?
Cheers,
--
Pete
Re: [C++] Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
On 04/12/06, Simon Laws <si...@googlemail.com> wrote:
>
> On 12/4/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> > Simon, your patch fails to apply with some wierd error at line 416! I
> have
> > backed out the change for 963. Could you try making your patch again?
> >
> > Cheers,
> >
> >
> > On 04/12/06, Pete Robbins <ro...@googlemail.com> wrote:
> > >
> > > Simon, I have also ben looking at a fix for 950 and although it is
> > fairly
> > > straightforward to fix the case in the Jira it gets rather complicated
> > when
> > > you consider properties that are not intended to be part of the
> sequence
> > (
> > > e.g. attributes but could be element properties that have been set
> > without
> > > using the sequence API).
> > >
> > > On 03/12/06, Simon Laws <si...@googlemail.com> wrote:
> > > >
> > > > On 12/3/06, Simon Laws <si...@googlemail.com> wrote:
> > > > >
> > > > > I've been working on a fix for 950 which I managed to complete so
> > that
> > > > you
> > > > > could successfully copy a DO tree containing both mixed and open
> > > > types. I
> > > > > then applied your fix for 963 and the resulting SDO fails. It
> > happily
> > > > does
> > > > > the copy still but won't print out elements in sequences or open
> > typed
> > > > > elements from the new DO that results from the copy.
> > > > >
> > >
> > >
> > > ... and this is exactly one of the issues I ran up against!!
> > >
> > > > Looking at the svn commit for 963 the main change seems to be to the
> > > > > SDOXMLWriter.
> > > > >
> > > > > // Do not write attributes as members of
> the
> > > > > sequence
> > > > > XSDPropertyInfo* pi =
> > > > getPropertyInfo(seqPropType,
> > > > > seqProp);
> > > > > PropertyDefinitionImpl propdef;
> > > > > if (!pi ||
> > > > > (pi->getPropertyDefinition().isElement))
> > > > > {
> > > > > continue;
> > > > > }
> > > > >
> > > > > I'm not au fait with how property info works but taking a tour
> round
> > > > the
> > > > > code it seems to be where the DAS keeps extra info derived from
> the
> > > > schema
> > > > > that is only used when writing back out to XML. The change finds,
> > from
> > > > the
> > > > > property info, those elements that are really attributes and hence
> > > > only
> > > > > writes them as attributes.
> > > > >
> > > > > 1/ The first thing that looks a little fishy is "if (!pi ||
> > > > > (pi->getPropertyDefinition().isElement))" which looks like it
> breaks
> > > > out of
> > > > > the loop if the property represents an element rather than when
> it's
> > > > not an
> > > > > element. Is this right?
> > > > >
> > >
> > >
> > > A better test here would be "have we already written this property as
> an
> > > attribute". The intent here is to only write properties that are
> > explicitly
> > > defined as elements.
> > >
> > > > Regardless of the correctness of this my copy doesn't work because
> > "!pi"
> > > > > is always true after I have copied the sequence. Can you explain
> to
> > me
> > > > how
> > > > > property information is intended to work. I need to know if I
> should
> > > > copy
> > > > > anything more than just the instance information. I had thought
> > > > everything
> > > > > else was in the model and hence I don't need to copy it.
> > > > >
> > >
> > >
> > > The PropertyInformation is basically a collection of information we
> > > remember from the schema to enable us to serialize it as a schema
> > intended.
> > > I believe we were going to add the ability to add this information
> > > programmatically and this may even have made it into the spec... I
> need
> > to
> > > check.
> > >
> > >
> > > > With the schema:
> > > > >
> > > > > <schema xmlns="http://www.w3.org/2001/XMLSchema "
> > > > > xmlns:tns="http://www.example.org/test "
> > > > > targetNamespace="http://www.example.org/test">
> > > > >
> > > > > <complexType name="CloneType" mixed="true">
> > > > > <sequence>
> > > > > <element name="test" type="string"/>
> > > > > <any namespace="##any"/>
> > > > > </sequence>
> > > > > </complexType>
> > > > >
> > > > > <element name="Clone" type="tns:CloneType"/>
> > > > >
> > > > > </schema>
> > > > >
> > > > > And the XML document:
> > > > >
> > > > > <Clone xmlns="http://www.example.org/test"
> > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> > > > > xsi:schemaLocation="http://www.example.org/test
> clone.xsd
> > ">
> > > > > abc
> > > > > <test>test</test>
> > > > > def
> > > > > <tests>test</tests>
> > > > > ghi
> > > > > </Clone>
> > > > >
> > > > > CloneType does have property info associated with it. But neither
> > > > > commonj.sdo.String (the type of test) or
> commonj.sdo.OpenDataObject
> > (the
> > > > > type of tests) have property info associated with them once the
> > schema
> > > > has
> > > > > been read. Hence it is not present in the model after the copy and
> > the
> > > > new
> > > > > writer doesn't write out "test" or "tests".
> > >
> > >
> > > Types never have PropertyInformation on them... nor will ANY open
> > property
> > > as these, by definition, are not defined by a schema. So this is where
> > my
> > > "fix" for 963 fails as your test and tests properties will never have
> > any pi
> > > associated with them.
> > >
> > > My changes (so far) are attached to
> > > > http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them
> > but
> > > > also as a backup.
> > >
> > >
> > >
> > > I'll take a look and see how close these are to my intended fix ;-)
> > >
> > > I'll also go back and revisit the 963 fix to cope with open types.
> > >
> > >
> > >
> > > Cheers,
> > >
> > > --
> > > Pete
> > >
> >
> >
> >
> > --
> > Pete
> >
> > Oh dear. I actutally tested applying this patch as well this time:-( It
> applies OK in Eclipse against a clean version of SDO. Can you shed any
> light
> on what the error is. As it was suggested last time that I should manually
> edit the patch to make it relative I did this to the satisfaction of the
> Eclipse application process but obviously messed it up us as far as what
> ever tool you use is concerned. If you give me a bit of info on the error
> I'll try and make a better patch.
>
> Simon
>
>
Simon's patches for TUSCANY-950 and TUSCANY-908 are now applied. I've also
checked in a fix for TUSCANY-960.
Cheers,
--
Pete
Re: [C++] Who is working on which SDO problems
Posted by Simon Laws <si...@googlemail.com>.
On 12/4/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> Simon, your patch fails to apply with some wierd error at line 416! I have
> backed out the change for 963. Could you try making your patch again?
>
> Cheers,
>
>
> On 04/12/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> > Simon, I have also ben looking at a fix for 950 and although it is
> fairly
> > straightforward to fix the case in the Jira it gets rather complicated
> when
> > you consider properties that are not intended to be part of the sequence
> (
> > e.g. attributes but could be element properties that have been set
> without
> > using the sequence API).
> >
> > On 03/12/06, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > On 12/3/06, Simon Laws <si...@googlemail.com> wrote:
> > > >
> > > > I've been working on a fix for 950 which I managed to complete so
> that
> > > you
> > > > could successfully copy a DO tree containing both mixed and open
> > > types. I
> > > > then applied your fix for 963 and the resulting SDO fails. It
> happily
> > > does
> > > > the copy still but won't print out elements in sequences or open
> typed
> > > > elements from the new DO that results from the copy.
> > > >
> >
> >
> > ... and this is exactly one of the issues I ran up against!!
> >
> > > Looking at the svn commit for 963 the main change seems to be to the
> > > > SDOXMLWriter.
> > > >
> > > > // Do not write attributes as members of the
> > > > sequence
> > > > XSDPropertyInfo* pi =
> > > getPropertyInfo(seqPropType,
> > > > seqProp);
> > > > PropertyDefinitionImpl propdef;
> > > > if (!pi ||
> > > > (pi->getPropertyDefinition().isElement))
> > > > {
> > > > continue;
> > > > }
> > > >
> > > > I'm not au fait with how property info works but taking a tour round
> > > the
> > > > code it seems to be where the DAS keeps extra info derived from the
> > > schema
> > > > that is only used when writing back out to XML. The change finds,
> from
> > > the
> > > > property info, those elements that are really attributes and hence
> > > only
> > > > writes them as attributes.
> > > >
> > > > 1/ The first thing that looks a little fishy is "if (!pi ||
> > > > (pi->getPropertyDefinition().isElement))" which looks like it breaks
> > > out of
> > > > the loop if the property represents an element rather than when it's
> > > not an
> > > > element. Is this right?
> > > >
> >
> >
> > A better test here would be "have we already written this property as an
> > attribute". The intent here is to only write properties that are
> explicitly
> > defined as elements.
> >
> > > Regardless of the correctness of this my copy doesn't work because
> "!pi"
> > > > is always true after I have copied the sequence. Can you explain to
> me
> > > how
> > > > property information is intended to work. I need to know if I should
> > > copy
> > > > anything more than just the instance information. I had thought
> > > everything
> > > > else was in the model and hence I don't need to copy it.
> > > >
> >
> >
> > The PropertyInformation is basically a collection of information we
> > remember from the schema to enable us to serialize it as a schema
> intended.
> > I believe we were going to add the ability to add this information
> > programmatically and this may even have made it into the spec... I need
> to
> > check.
> >
> >
> > > With the schema:
> > > >
> > > > <schema xmlns="http://www.w3.org/2001/XMLSchema "
> > > > xmlns:tns="http://www.example.org/test "
> > > > targetNamespace="http://www.example.org/test">
> > > >
> > > > <complexType name="CloneType" mixed="true">
> > > > <sequence>
> > > > <element name="test" type="string"/>
> > > > <any namespace="##any"/>
> > > > </sequence>
> > > > </complexType>
> > > >
> > > > <element name="Clone" type="tns:CloneType"/>
> > > >
> > > > </schema>
> > > >
> > > > And the XML document:
> > > >
> > > > <Clone xmlns="http://www.example.org/test"
> > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> > > > xsi:schemaLocation="http://www.example.org/test clone.xsd
> ">
> > > > abc
> > > > <test>test</test>
> > > > def
> > > > <tests>test</tests>
> > > > ghi
> > > > </Clone>
> > > >
> > > > CloneType does have property info associated with it. But neither
> > > > commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject
> (the
> > > > type of tests) have property info associated with them once the
> schema
> > > has
> > > > been read. Hence it is not present in the model after the copy and
> the
> > > new
> > > > writer doesn't write out "test" or "tests".
> >
> >
> > Types never have PropertyInformation on them... nor will ANY open
> property
> > as these, by definition, are not defined by a schema. So this is where
> my
> > "fix" for 963 fails as your test and tests properties will never have
> any pi
> > associated with them.
> >
> > My changes (so far) are attached to
> > > http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them
> but
> > > also as a backup.
> >
> >
> >
> > I'll take a look and see how close these are to my intended fix ;-)
> >
> > I'll also go back and revisit the 963 fix to cope with open types.
> >
> >
> >
> > Cheers,
> >
> > --
> > Pete
> >
>
>
>
> --
> Pete
>
> Oh dear. I actutally tested applying this patch as well this time:-( It
applies OK in Eclipse against a clean version of SDO. Can you shed any light
on what the error is. As it was suggested last time that I should manually
edit the patch to make it relative I did this to the satisfaction of the
Eclipse application process but obviously messed it up us as far as what
ever tool you use is concerned. If you give me a bit of info on the error
I'll try and make a better patch.
Simon
Re: [C++] Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
Simon, your patch fails to apply with some wierd error at line 416! I have
backed out the change for 963. Could you try making your patch again?
Cheers,
On 04/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> Simon, I have also ben looking at a fix for 950 and although it is fairly
> straightforward to fix the case in the Jira it gets rather complicated when
> you consider properties that are not intended to be part of the sequence (
> e.g. attributes but could be element properties that have been set without
> using the sequence API).
>
> On 03/12/06, Simon Laws <si...@googlemail.com> wrote:
> >
> > On 12/3/06, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > I've been working on a fix for 950 which I managed to complete so that
> > you
> > > could successfully copy a DO tree containing both mixed and open
> > types. I
> > > then applied your fix for 963 and the resulting SDO fails. It happily
> > does
> > > the copy still but won't print out elements in sequences or open typed
> > > elements from the new DO that results from the copy.
> > >
>
>
> ... and this is exactly one of the issues I ran up against!!
>
> > Looking at the svn commit for 963 the main change seems to be to the
> > > SDOXMLWriter.
> > >
> > > // Do not write attributes as members of the
> > > sequence
> > > XSDPropertyInfo* pi =
> > getPropertyInfo(seqPropType,
> > > seqProp);
> > > PropertyDefinitionImpl propdef;
> > > if (!pi ||
> > > (pi->getPropertyDefinition().isElement))
> > > {
> > > continue;
> > > }
> > >
> > > I'm not au fait with how property info works but taking a tour round
> > the
> > > code it seems to be where the DAS keeps extra info derived from the
> > schema
> > > that is only used when writing back out to XML. The change finds, from
> > the
> > > property info, those elements that are really attributes and hence
> > only
> > > writes them as attributes.
> > >
> > > 1/ The first thing that looks a little fishy is "if (!pi ||
> > > (pi->getPropertyDefinition().isElement))" which looks like it breaks
> > out of
> > > the loop if the property represents an element rather than when it's
> > not an
> > > element. Is this right?
> > >
>
>
> A better test here would be "have we already written this property as an
> attribute". The intent here is to only write properties that are explicitly
> defined as elements.
>
> > Regardless of the correctness of this my copy doesn't work because "!pi"
> > > is always true after I have copied the sequence. Can you explain to me
> > how
> > > property information is intended to work. I need to know if I should
> > copy
> > > anything more than just the instance information. I had thought
> > everything
> > > else was in the model and hence I don't need to copy it.
> > >
>
>
> The PropertyInformation is basically a collection of information we
> remember from the schema to enable us to serialize it as a schema intended.
> I believe we were going to add the ability to add this information
> programmatically and this may even have made it into the spec... I need to
> check.
>
>
> > With the schema:
> > >
> > > <schema xmlns="http://www.w3.org/2001/XMLSchema "
> > > xmlns:tns="http://www.example.org/test "
> > > targetNamespace="http://www.example.org/test">
> > >
> > > <complexType name="CloneType" mixed="true">
> > > <sequence>
> > > <element name="test" type="string"/>
> > > <any namespace="##any"/>
> > > </sequence>
> > > </complexType>
> > >
> > > <element name="Clone" type="tns:CloneType"/>
> > >
> > > </schema>
> > >
> > > And the XML document:
> > >
> > > <Clone xmlns="http://www.example.org/test"
> > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> > > xsi:schemaLocation="http://www.example.org/test clone.xsd">
> > > abc
> > > <test>test</test>
> > > def
> > > <tests>test</tests>
> > > ghi
> > > </Clone>
> > >
> > > CloneType does have property info associated with it. But neither
> > > commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject(the
> > > type of tests) have property info associated with them once the schema
> > has
> > > been read. Hence it is not present in the model after the copy and the
> > new
> > > writer doesn't write out "test" or "tests".
>
>
> Types never have PropertyInformation on them... nor will ANY open property
> as these, by definition, are not defined by a schema. So this is where my
> "fix" for 963 fails as your test and tests properties will never have any pi
> associated with them.
>
> My changes (so far) are attached to
> > http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them but
> > also as a backup.
>
>
>
> I'll take a look and see how close these are to my intended fix ;-)
>
> I'll also go back and revisit the 963 fix to cope with open types.
>
>
>
> Cheers,
>
> --
> Pete
>
--
Pete
Re: [C++] Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
Simon, I have also ben looking at a fix for 950 and although it is fairly
straightforward to fix the case in the Jira it gets rather complicated when
you consider properties that are not intended to be part of the sequence (
e.g. attributes but could be element properties that have been set without
using the sequence API).
On 03/12/06, Simon Laws <si...@googlemail.com> wrote:
>
> On 12/3/06, Simon Laws <si...@googlemail.com> wrote:
> >
> > I've been working on a fix for 950 which I managed to complete so that
> you
> > could successfully copy a DO tree containing both mixed and open types.
> I
> > then applied your fix for 963 and the resulting SDO fails. It happily
> does
> > the copy still but won't print out elements in sequences or open typed
> > elements from the new DO that results from the copy.
> >
... and this is exactly one of the issues I ran up against!!
> Looking at the svn commit for 963 the main change seems to be to the
> > SDOXMLWriter.
> >
> > // Do not write attributes as members of the
> > sequence
> > XSDPropertyInfo* pi =
> getPropertyInfo(seqPropType,
> > seqProp);
> > PropertyDefinitionImpl propdef;
> > if (!pi ||
> > (pi->getPropertyDefinition().isElement))
> > {
> > continue;
> > }
> >
> > I'm not au fait with how property info works but taking a tour round the
> > code it seems to be where the DAS keeps extra info derived from the
> schema
> > that is only used when writing back out to XML. The change finds, from
> the
> > property info, those elements that are really attributes and hence only
> > writes them as attributes.
> >
> > 1/ The first thing that looks a little fishy is "if (!pi ||
> > (pi->getPropertyDefinition().isElement))" which looks like it breaks out
> of
> > the loop if the property represents an element rather than when it's not
> an
> > element. Is this right?
> >
A better test here would be "have we already written this property as an
attribute". The intent here is to only write properties that are explicitly
defined as elements.
> Regardless of the correctness of this my copy doesn't work because "!pi"
> > is always true after I have copied the sequence. Can you explain to me
> how
> > property information is intended to work. I need to know if I should
> copy
> > anything more than just the instance information. I had thought
> everything
> > else was in the model and hence I don't need to copy it.
> >
The PropertyInformation is basically a collection of information we remember
from the schema to enable us to serialize it as a schema intended. I believe
we were going to add the ability to add this information programmatically
and this may even have made it into the spec... I need to check.
> With the schema:
> >
> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> > xmlns:tns="http://www.example.org/test "
> > targetNamespace="http://www.example.org/test">
> >
> > <complexType name="CloneType" mixed="true">
> > <sequence>
> > <element name="test" type="string"/>
> > <any namespace="##any"/>
> > </sequence>
> > </complexType>
> >
> > <element name="Clone" type="tns:CloneType"/>
> >
> > </schema>
> >
> > And the XML document:
> >
> > <Clone xmlns="http://www.example.org/test"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> > xsi:schemaLocation="http://www.example.org/test clone.xsd ">
> > abc
> > <test>test</test>
> > def
> > <tests>test</tests>
> > ghi
> > </Clone>
> >
> > CloneType does have property info associated with it. But neither
> > commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject (the
> > type of tests) have property info associated with them once the schema
> has
> > been read. Hence it is not present in the model after the copy and the
> new
> > writer doesn't write out "test" or "tests".
Types never have PropertyInformation on them... nor will ANY open property
as these, by definition, are not defined by a schema. So this is where my
"fix" for 963 fails as your test and tests properties will never have any pi
associated with them.
My changes (so far) are attached to
> http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them but
> also as a backup.
I'll take a look and see how close these are to my intended fix ;-)
I'll also go back and revisit the 963 fix to cope with open types.
Cheers,
--
Pete
Re: [C++] Who is working on which SDO problems
Posted by Simon Laws <si...@googlemail.com>.
On 12/3/06, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 12/1/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> > Fix now checked in for TUSCANY-963.
> >
> > On 01/12/06, Pete Robbins <ro...@googlemail.com> wrote:
> > >
> > >
> > >
> > > On 01/12/06, Caroline Maynard < caroline.maynard@gmail.com> wrote:
> > > >
> > > > I created http://issues.apache.org/jira/browse/TUSCANY-963 for the
> > > > "attributes as elements" problem.
> > >
> > >
> > > I'm working on this. I see the problem and should be able to get a fix
> > > soon.
> > >
> > > Cheers,
> > >
> > > --
> > > Pete
> > >
> >
> >
> >
> > --
> > Pete
> >
> > Hi Pete
>
> I've been working on a fix for 950 which I managed to complete so that you
> could successfully copy a DO tree containing both mixed and open types. I
> then applied your fix for 963 and the resulting SDO fails. It happily does
> the copy still but won't print out elements in sequences or open typed
> elements from the new DO that results from the copy.
>
> Looking at the svn commit for 963 the main change seems to be to the
> SDOXMLWriter.
>
> // Do not write attributes as members of the
> sequence
> XSDPropertyInfo* pi = getPropertyInfo(seqPropType,
> seqProp);
> PropertyDefinitionImpl propdef;
> if (!pi ||
> (pi->getPropertyDefinition().isElement))
> {
> continue;
> }
>
> I'm not au fait with how property info works but taking a tour round the
> code it seems to be where the DAS keeps extra info derived from the schema
> that is only used when writing back out to XML. The change finds, from the
> property info, those elements that are really attributes and hence only
> writes them as attributes.
>
> 1/ The first thing that looks a little fishy is "if (!pi ||
> (pi->getPropertyDefinition().isElement))" which looks like it breaks out of
> the loop if the property represents an element rather than when it's not an
> element. Is this right?
>
> Regardless of the correctness of this my copy doesn't work because "!pi"
> is always true after I have copied the sequence. Can you explain to me how
> property information is intended to work. I need to know if I should copy
> anything more than just the instance information. I had thought everything
> else was in the model and hence I don't need to copy it.
>
> With the schema:
>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> xmlns:tns="http://www.example.org/test "
> targetNamespace="http://www.example.org/test">
>
> <complexType name="CloneType" mixed="true">
> <sequence>
> <element name="test" type="string"/>
> <any namespace="##any"/>
> </sequence>
> </complexType>
>
> <element name="Clone" type="tns:CloneType"/>
>
> </schema>
>
> And the XML document:
>
> <Clone xmlns="http://www.example.org/test"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
> xsi:schemaLocation="http://www.example.org/test clone.xsd ">
> abc
> <test>test</test>
> def
> <tests>test</tests>
> ghi
> </Clone>
>
> CloneType does have property info associated with it. But neither
> commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject (the
> type of tests) have property info associated with them once the schema has
> been read. Hence it is not present in the model after the copy and the new
> writer doesn't write out "test" or "tests".
>
> Regards
>
> Simon
>
My changes (so far) are attached to
http://issues.apache.org/jira/browse/TUSCANY-950 so you can see them but
also as a backup.
Simon
Re: [C++] Who is working on which SDO problems
Posted by Simon Laws <si...@googlemail.com>.
On 12/1/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> Fix now checked in for TUSCANY-963.
>
> On 01/12/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> >
> >
> > On 01/12/06, Caroline Maynard <ca...@gmail.com> wrote:
> > >
> > > I created http://issues.apache.org/jira/browse/TUSCANY-963 for the
> > > "attributes as elements" problem.
> >
> >
> > I'm working on this. I see the problem and should be able to get a fix
> > soon.
> >
> > Cheers,
> >
> > --
> > Pete
> >
>
>
>
> --
> Pete
>
> Hi Pete
I've been working on a fix for 950 which I managed to complete so that you
could successfully copy a DO tree containing both mixed and open types. I
then applied your fix for 963 and the resulting SDO fails. It happily does
the copy still but won't print out elements in sequences or open typed
elements from the new DO that results from the copy.
Looking at the svn commit for 963 the main change seems to be to the
SDOXMLWriter.
// Do not write attributes as members of the
sequence
XSDPropertyInfo* pi = getPropertyInfo(seqPropType,
seqProp);
PropertyDefinitionImpl propdef;
if (!pi || (pi->getPropertyDefinition().isElement))
{
continue;
}
I'm not au fait with how property info works but taking a tour round the
code it seems to be where the DAS keeps extra info derived from the schema
that is only used when writing back out to XML. The change finds, from the
property info, those elements that are really attributes and hence only
writes them as attributes.
1/ The first thing that looks a little fishy is "if (!pi ||
(pi->getPropertyDefinition().isElement))" which looks like it breaks out of
the loop if the property represents an element rather than when it's not an
element. Is this right?
Regardless of the correctness of this my copy doesn't work because "!pi" is
always true after I have copied the sequence. Can you explain to me how
property information is intended to work. I need to know if I should copy
anything more than just the instance information. I had thought everything
else was in the model and hence I don't need to copy it.
With the schema:
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.example.org/test"
targetNamespace="http://www.example.org/test">
<complexType name="CloneType" mixed="true">
<sequence>
<element name="test" type="string"/>
<any namespace="##any"/>
</sequence>
</complexType>
<element name="Clone" type="tns:CloneType"/>
</schema>
And the XML document:
<Clone xmlns="http://www.example.org/test"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.example.org/test clone.xsd ">
abc
<test>test</test>
def
<tests>test</tests>
ghi
</Clone>
CloneType does have property info associated with it. But neither
commonj.sdo.String (the type of test) or commonj.sdo.OpenDataObject (the
type of tests) have property info associated with them once the schema has
been read. Hence it is not present in the model after the copy and the new
writer doesn't write out "test" or "tests".
Regards
Simon
Re: [C++] Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
Fix now checked in for TUSCANY-963.
On 01/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>
>
>
> On 01/12/06, Caroline Maynard <ca...@gmail.com> wrote:
> >
> > I created http://issues.apache.org/jira/browse/TUSCANY-963 for the
> > "attributes as elements" problem.
>
>
> I'm working on this. I see the problem and should be able to get a fix
> soon.
>
> Cheers,
>
> --
> Pete
>
--
Pete
Re: [C++] Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
On 01/12/06, Caroline Maynard <ca...@gmail.com> wrote:
>
> I created http://issues.apache.org/jira/browse/TUSCANY-963 for the
> "attributes as elements" problem.
I'm working on this. I see the problem and should be able to get a fix soon.
Cheers,
--
Pete
Re: [C++] Who is working on which SDO problems
Posted by Caroline Maynard <ca...@gmail.com>.
I created http://issues.apache.org/jira/browse/TUSCANY-963 for the
"attributes as elements" problem.
The WSDL problem was http://issues.apache.org/jira/browse/TUSCANY-962, which
Pete has a fix for.
Re: [C++] Who is working on which SDO problems
Posted by Pete Robbins <ro...@googlemail.com>.
On 01/12/06, Simon Laws <si...@googlemail.com> wrote:
>
> On 12/1/06, Geoffrey Winn <ge...@googlemail.com> wrote:
> >
> > On 01/12/06, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > I have been chatting with the PHP SCA team about their various SDO
> > > problems
> > > and I would be interested to know who is working on what so I look at
> > > things
> > > in transit. I'm particularly interested in the following problems:
> > >
> > > http://issues.apache.org/jira/browse/TUSCANY-960 - Spurious
> > > xsi:type="OpenDataObject" attribute generated
> > > http://issues.apache.org/jira/browse/TUSCANY-950 - Copy helper forgets
> > > sequence information
> > > (not sure which bug - i seem to remember a post about it) - Attributes
> > > repeated as elements on output
> > > http://issues.apache.org/jira/browse/TUSCANY-873 - I'm going to open
> > this
> > > one up again if I can as it's got a bit missing w.r.t copying open
> > > content.
> > >
> > > But of course it would be worth noting anything else that's going on
> at
> > > the
> > > moment that might have an impact on copying problems
> > >
> > > Regards
> > >
> > > Simon
> > >
> > >
> > I'll be on vacation for the first three days of next week, but when I
> get
> > back I'll take a look at whichever ones need attention.
> >
> > Regards,
> >
> > Geoff.
>
>
> Great, thx Geoff. Have a good time. I pinged Caroline off line and she is
> working with Pete on a WSDL problem so I think the answer is that no one
> is
> currently working on any of these. I have created a fix to make copying
> work
> properly when there are many valued types in the DO (a feature of open
> types). I'll attach this to a 873 shortly as this is an extension of the
> existing fix. I'll now have a crack at 950.
>
> Simon
>
>
Thanls Simon. I seem to have many "urgent" things on the go ;-)
I'll review and apply patches if needed before Geoff returns.
Cheers,
--
Pete
Re: [C++] Who is working on which SDO problems
Posted by Simon Laws <si...@googlemail.com>.
On 12/1/06, Geoffrey Winn <ge...@googlemail.com> wrote:
>
> On 01/12/06, Simon Laws <si...@googlemail.com> wrote:
> >
> > I have been chatting with the PHP SCA team about their various SDO
> > problems
> > and I would be interested to know who is working on what so I look at
> > things
> > in transit. I'm particularly interested in the following problems:
> >
> > http://issues.apache.org/jira/browse/TUSCANY-960 - Spurious
> > xsi:type="OpenDataObject" attribute generated
> > http://issues.apache.org/jira/browse/TUSCANY-950 - Copy helper forgets
> > sequence information
> > (not sure which bug - i seem to remember a post about it) - Attributes
> > repeated as elements on output
> > http://issues.apache.org/jira/browse/TUSCANY-873 - I'm going to open
> this
> > one up again if I can as it's got a bit missing w.r.t copying open
> > content.
> >
> > But of course it would be worth noting anything else that's going on at
> > the
> > moment that might have an impact on copying problems
> >
> > Regards
> >
> > Simon
> >
> >
> I'll be on vacation for the first three days of next week, but when I get
> back I'll take a look at whichever ones need attention.
>
> Regards,
>
> Geoff.
Great, thx Geoff. Have a good time. I pinged Caroline off line and she is
working with Pete on a WSDL problem so I think the answer is that no one is
currently working on any of these. I have created a fix to make copying work
properly when there are many valued types in the DO (a feature of open
types). I'll attach this to a 873 shortly as this is an extension of the
existing fix. I'll now have a crack at 950.
Simon
Re: [C++] Who is working on which SDO problems
Posted by Geoffrey Winn <ge...@googlemail.com>.
On 01/12/06, Simon Laws <si...@googlemail.com> wrote:
>
> I have been chatting with the PHP SCA team about their various SDO
> problems
> and I would be interested to know who is working on what so I look at
> things
> in transit. I'm particularly interested in the following problems:
>
> http://issues.apache.org/jira/browse/TUSCANY-960 - Spurious
> xsi:type="OpenDataObject" attribute generated
> http://issues.apache.org/jira/browse/TUSCANY-950 - Copy helper forgets
> sequence information
> (not sure which bug - i seem to remember a post about it) - Attributes
> repeated as elements on output
> http://issues.apache.org/jira/browse/TUSCANY-873 - I'm going to open this
> one up again if I can as it's got a bit missing w.r.t copying open
> content.
>
> But of course it would be worth noting anything else that's going on at
> the
> moment that might have an impact on copying problems
>
> Regards
>
> Simon
>
>
I'll be on vacation for the first three days of next week, but when I get
back I'll take a look at whichever ones need attention.
Regards,
Geoff.