xml-dev - [Fwd: Sun XML early access]

["Simon St.Laurent" <simonstl@simonstl.com>]

Forwarded for David Brownell:

[ My posts to this list generally get swallowed somewhere, so
I expect to need to forward this manually ... ]

Tyler Baker wrote:
> 
> Michael Kay wrote:
> 
> > Actually I'm not sure subclassing Element with a "semantic"
> > subclass, e.g. a business object such as Invoice, is the
> > right approach, because you get a clumsy class heirarchy,
> > and you invite the user to override methods inappropriately.

The API to that feature is subject to change, more than most
other parts of the library.  For example, it's not yet aware
of namespaces.  We see such subclassing as only one of several
tools that need to exist.  (Any tool can be misused!)

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 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.


> > I'd prefer to have the Element contain a "userObject"
> > pointer to the business object.

Such a delegation approach is necessary in any case, since
it's important to integrate into frameworks that already
define their own base class.  Is it sufficient?  Hmmm ...
almost certainly not, IMHO.  Even so, it's on the roadmap.


> I pretty much never ever subclass anything for typing purposes
> except as a code reuse policy.  I have already learned the hard
> way that this sort of approach builds highly inflexible and
> highly inefficient systems.

It also builds flexible and efficient ones.  One uses the right
tool for the problem, and sometimes subclassing is that tool.


>	  Every major Java ISV out there seems to get
> this other than SUN who still seems to prefer the subclassing
> approach in their  designs.

Remember that this functionality is documented as "experimental"
and subject to change ... also, that quite a few systems have
had real success with this particular style of subclassing.

Many XML related ones too!  COINS, IBM's XML4J, and more.  The
Raven editor uses this (and other techniques), and a number of
HTML display packages too.  I was intrigued by the statistics
Steve Withall presented at the XML Developer's conference,
showing that by far the bulk of the customization code was
associated with elements.  (See his XML Testbed, on "xml.com"!)


>	  Maybe this is for some potential
> purpose of vendor lock in.  Who really knows.

I do, I do!!  There are no such dark motives lurking here.

- Dave


Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
http://www.simonstl.com

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)