Lists Home |
Date Index |
- From: "Rzepa, Henry" <firstname.lastname@example.org>
- To: email@example.com
- Date: Sat, 26 Sep 1998 08:21:12 +0100
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.
Henry Rzepa. +44 171 594 5774 (Office) +44 171 594 5804 (Fax)
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)