On 12/4/06, Pete Robbins <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >
> > On 12/3/06, Simon Laws <[EMAIL PROTECTED]> 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
