XML [~serialization] and Objects

[David Brownell]

(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)