xml-dev - Re: XML [~serialization] and Objects

[Michael Amster <mamster@webeasy.com>]

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@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)

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

begin:vcard
n:Amster;Michael
tel;fax:(310) 576-2011
tel;work:(310) 576-0770
x-mozilla-html:TRUE
org:WebEasy
version:2.1
email;internet:mamster@webeasy.com
title:Chief Technology Officer
adr;quoted-printable;quoted-printable:;;4676 Admiralty Way=0D=0A=
	Suite 300;Marina Del Rey;CA;90292;US
fn:Michael Amster
end:vcard