[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML and Objects

• From: David Brownell <db@E...>
• To: "XML Developers' List" <xml-dev@i...>
• Date: Tue, 29 Sep 1998 00:28:31 -0700

david@m... wrote:
> 
> Gregory M. Messner writes:
> 
>  > I am leaning towards multipart/related, but would like to know of
>  > others experience in this area.
> 
> The key is to use a streaming protocol so that you can start
> processing the first files while the rest are arriving.  ZIP is
> useless for this purpose, since it keeps the directory information at
> the end; TAR is good, as (I think) is CPIO.

The Java ARchive (JAR) format has manifests at the very beginning,
so that the correct digital signatures can be computed during download.
This can be used with non-Java systems, but nowadays I have the worst
time understanding why anyone would work with any other system!  ;-)


>  > 2) We desire to provide an API on the client side which exposes a
>  > simple mechanism for creating and modifying objects. These objects
>  > are serialized using XML and then transported to a server for
>  > further processing. The server then responds with another XML
>  > document that we then de-serialize into an object and present it to
>  > the API user. Here are some basic requirements:
>  >
>  >     * Support for both Java and C++
>  >     * API must be similar for both Java and C++
>  >     * Object members are accessed via get/set methods
>  >     * Adhere to JavaBean method naming patterns
> 
> The DOM would be a pretty close (and obvious) fit, and has the
> advantage of being very close to W3C Recommendation.

Yes, but ... it depends on what's meant by serialize/deserialize
though.  There are quite a few options there (in just XML systems,
four come quickly to mind!) so more info may be helpful.  DOM does
not say how to read or write DOM objects, and nodes don't really
have get/set method naming for "data" (just DOM info).  Other sorts
of solution may be closer to what Gregory wanted.

For example, in Java it's (way) easy to put together something that
can "serialize" (not in the "java.io" sense though) beans like:

	<BEAN CLASS="com.example.foo.SimpleBean">
	    <PROPERTY NAME="prop1" DCD:i4>49</PROPERTY>
	    <PROPERTY NAME="prop2" DCD:string>hello world</PROPERTY>
	    ...
	    </BEAN>

Then reading it back in Java is a case of taking the "CLASS" tag
and instantiating, then assigning properties.  In C++ it'd need a
table associating that class with some custom generated C++ stuff.
Plus of course there are corner cases like wanting to emit strings
containing characters that are not legal XML -- formfeed, BEL, and
so on.  (That'd be one reason why when I did such stuff, I didn't
use DCD.)  Reflection makes stuff like that rather simple to do;
you can use custom generated code, but don't need to.

That particular solution doesn't require DOM at all. 

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: XML and Objects
    • From: Mark Baker <mark@c...>
  • Re: XML and Objects
    • From: Chris Hubick <maillist@c...>

• References:
  • XML and Objects
    • From: "Gregory M. Messner" <gmessner@m...>
  • XML and Objects
    • From: <david@m...>

• Prev by Date: Re: DCD v DTD?
• Next by Date: Re: XML and Objects
• Previous by thread: Re: XML and Objects
• Next by thread: Re: XML and Objects
• Index(es):
  • Date
  • Thread