The C++ serializer works as Jeremy states. We would serialize this as <
implementation.java>. Our implementation does keep extra information about
the substitution groups and also what the original local name was when the
instance doc was deserialized. So if it was deserialized as <
implementation.Fred> then it would be serialized as the same element name.
I'm not sure what would happen if we created a dataobject programmatically
(as opposed to loading an xml doc) and set the property "implementation" to
something of type sca:implemantionJava. In that case we would not have
enough info to serialise it as anything other than <implementation ...>. I
guess we could check all our substitution groups and serialize as the one
that is the correct type... in fact our code may do that, I'd have to check
with Ed.
Of course this would not work if you have 2 substitution groups of the same
type as in Frank's example.
But... we can round-trip so deserialization followed by serialization should
produce equivalent xml.
Cheers,
On 15/06/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:
Jeremy,
Unfortunately XML isn't as simple as your expectations. There are two
dimensions of specialization in XML vs. just one in Java.
In both XML and Java you can have type B extend A.
But in XML you can also have the equivalent of variable b : B extend
variable a : A. So, you can have examples of one, the other, or both,
being used.
<complexType name="A"> ... </complexType>
<complexType name="B">
<complexContent>
<extension base="A"> ... </extension>
</complexContent>
</complexType>
<element name="a" type="A"/>
<element name="b" substitutionGroup="a" type="B"/>
<element name="c" substitutionGroup="a" type="B"/>
So an SDO property "a" of type "B" could be legally serialized in any of
the following ways:
<a xsi:type="B"> ... </a>
<b> ... </b>
<c> ... </c>
So unless we store some additional information somewhere (in the object),
there's no way to know which one to use. Since substitutionGroup members
are global elements, they naturally fall into the open content model of
SDO, but I think we may be better off hiding them and only exposing them
to the serializer.
Welcome to the wacky world of XML binding :-)
Frank.
Jeremy Boynes <[EMAIL PROTECTED]> wrote on 06/14/2006 06:21:47 PM:
> Frank Budinsky wrote:
> > Raymond is trying to write a serializer, and I presume he wants to
produce
> > this:
> >
> > <implementation.java ...>
> >
> > If the only property on the object is "implementation" with a value
that
> > is an sca:Implementation subclass, you'd get/expect this when
serializing:
> >
> > <implementation xsi:type="sca:JavaImplementation" ...>
> >
> > which is valid, but isn't using the substitution group.
>
> I would have expected the serializer be aware of the substitution group
> and write out the element corresponding the actual value assigned to the
> property.
>
> IOW I would not have expected
> <implementation xsi:type="sca:JavaImplementation" ...>
> but
> <implementation.java ...>
>
> >
> > So it's really the "implementation.java" property that we need to
> > serialize, but the "implementation" property is a static property of
the
> > Type, so it will always be there. In the Java implementation they both
> > return the same thing, but the serializer needs to know that one is
just
> > derived from the other and not to serialize them both.
> >
>
> There's only one property in question here ("implementation") - it's
> just that the property supports an entire hierarchy of value types.
>
> > More generally, I'm wondering how the C++ implementation will
serialize
> > this. Does it roundtrip back to the same XML that was loaded?
> >
>
> One would hope so :-)
> --
> Jeremy
>
> ---------------------------------------------------------------------
> 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]
--
Pete
