Hi Pete,
Your approach of hiding the extra state sounds reasonable - in fact, it
sounds similar to the SAP implementation approach from what I've gathered.
Both of you have the same problem, however, if you want full XML Schema
support (For example, to programmatically create an objects that will
serialize using <c> ,,, </c> in my example, below).
I think that the spec needs to address this issue in a standard way, so
I've added this to the spec discussion. You might want to follow issue
SDO-78 to see/influence where this goes.
Frank.
"Pete Robbins" <[EMAIL PROTECTED]> wrote on 06/15/2006 02:51:19 AM:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
