xml-dev - Java/XML/SUN (was: Re: Fwd: Why can't I post to XML-Dev?)

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

At 08:21 26/09/98 +0100, Rzepa, Henry wrote:
>Forwarded from From: David Brownell <db@Eng.Sun.COM>

Thanks very much David - haven't yet had time to look at the classes. Some
simple comments on your comments:

>>
>>One thing that comes from subclassing is the ability to modify
>>the tree construction dynamically.  You can optimize in-memory
>>representations easily -- e.g. removing ignorable whitespace and
>>things like redundant representations of data (cutting memory
>>use by quite a bit!).  Also, anyone who's really manipulating
>>text will need more than DOM should even think of supporting.

I certainly find this an important point. Some objects (like HTML/IBTWSH)
can contain a large number of nodes. Tree-building (using
com.sun.java.swing.tree.DefaultMutableTreeNode) seems expensive when there
are lots of nodes and I now find myself writing subclasses to manage these.
For example jumbo.xml.data.HTMLNode is subclassed from DMTN and will hold
the HTML element as a serialised String. When it needs display it can be
unpacked. 

>>I think it'd be generally true that the semantic model that
>>is used by an application would not always conform to the XML
>>structure, exposed by DOM.  An example we've used is that of
>>a 3D spreadsheet.  The internal representation will need to be
>>highly optimized for most things; tables will be either dense
>>or sparse arrays, with "slice" operations, for starters.  It
>>could be fine to have such an optimized object "boxed" inside
>>a DOM document, minimizing the need for document-specific
>>navigation APIs and maximizing code reuse.  No need to have an
>>XML-oriented representation of that core data also lingering
>>around -- that's needed for externalization, period.

Agreed. And for this sort of thing (e.g. Molecules) I pack the XML event
stream into a more suitable representation. It means that for these type of
classes I use a set of routines such as:
	processXML()	- called in SAX to pack (and verify) elements
	processEventStream()	- outputs the internal representation as an XML
stream (variations such as prettyprinting, whitespace, etc. can be controlled)
	getDisplayComponent()	- returns an editable JComponent

It would be great if we could standardise on the API for this sort of
thing. Then element-oriented programming could become really attractive.
The domain-specific classes could use a standard core facility.


	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

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)