xml-dev - Fwd: Why can't I post to XML-Dev?

["Rzepa, Henry" <h.rzepa@ic.ac.uk>]

Forwarded from From: David Brownell <db@Eng.Sun.COM>

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

Henry Rzepa. +44 171 594 5774 (Office) +44 171 594 5804 (Fax)
http://www.ch.ic.ac.uk/rzepa/

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)