XML [~serialization] and Objects

[Michael Amster]

If we are working in a purely Java environment, I don't believe that a DTD is
particularly valuable.  Introspection allows for runtime errors to be detected
and handled.  It is up to the serialization/deserialization to classify mandatory
and optional fields in an object.

The neat (pardon that word) thing about this is that if we have a "smart"
serialization/deserialization mechanism, we can deal with object versioning
cleanly.  Current methods assume identical object definitions on both sides of
the wire.  If this is not the case, XML serialization coupled with a ruleset for
object reconstruction (don't care, mandatory, optional, default) can accomodate
different versions of objects.

Just a thought.

-MA

David Brownell wrote:

> (Welcome back, Steve!  ;-)
>
> Steve Withall wrote:
> >
> > At 00:28 29/9/98 -0700, David Brownell wrote:
> > >
> > >       <BEAN CLASS="com.example.foo.SimpleBean">
> > >           <PROPERTY NAME="prop1" DCD:i4>49</PROPERTY>
> > >           <PROPERTY NAME="prop2" DCD:string>hello world</PROPERTY>
> > >           ...
> > >           </BEAN>
> >
> > The problem I have with this approach is that it limits you to
> > specifying just a single class. Surely in the general case
>
> This solution wasn't for a general case -- it was for a specific
> one, serializing some Java data to/from XML using particular DTD
> so that non-Java code could _potentially_ generate.  Many such
> solutions are possible.
>
> >        one
> > wants to be able to use an XML element to represent some sort
> > of 'thing' (avoiding the word object), and it should be possible
> > for multiple applications to use this XML document, each one
> > possibly wishing to instantiate the 'thing' using a different class.
>
> In the general case I'd go so far as to say that _some_ elements
> represent a "thing", and many don't.  Existing DTDs aren't all done
> with a particular object modeling paradigm, and so on.  One can't
> deduce which elements represent objects, which represent properties,
> which represent actions, and so forth without a data model in hand.
>
> In the example above, that data model was captured in the spec for
> that java class, which can be introspected at runtime.  In general,
> that assumption must not be made.  (But it can simplify things a
> whole bunch in those cases where you can assume a java.lang.Class!)
>
> > I'd prefer the identification of which class a particular
> > application should use for a particular type of element to
> > be external (using DCD, for example). The document itself then
> > remains 'purer'...
>
> Right, that's a more general approach, and is very much akin to
> the experimental "XML Beans" stuff in Sun's XML Library.  The
> association is external to the document, and existing documents
> can be used in a variety of ways.
>
> As I noted elsewhere, I see those two approaches as basically
> separate.  They can be hybridized, but I suspect that'd cause
> confusion if not done with care.
>
> - Dave
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)

--
~-~-~-~-~-~-~-~-~-~-~-~-~-~-WEBEASY-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Michael Amster     mamster at webeasy.com
4676 Admiralty Way, Suite 300   Tel: 310.576.0770
Marina Del Rey, CA 90292   Fax: 310.576.2011

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mamster.vcf
Type: text/x-vcard
Size: 319 bytes
Desc: Card for Michael Amster
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980929/fa39379f/mamster.vcf