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

Re: Compound Documents - necessary for success?

• From: jamsden@u...
• To: costello@m... (Roger L. Costello)
• Date: Wed, 27 Jan 1999 13:39:08 -0500

Your comments are well placed, but there are a few considerations that
could be added. First, XML is about data interchange, not object models.
Objects encapsulate state and behavior while XML only describes document
structure. So the analogy with objects is only partial. Encapsulation
achieves its greatest benefit by separating interface from implementation
through methods. XML exposes the implementation in the structure of the
document.  Hence the many arguments about attributes vs. content model.
This wouldn't exist for an object model that hides the implementation.
Generalization and specialization (inheritance) also achieve their greatest
benefit with behavior, not state. A specialization would never want to
override data in its superclass, only the implementation of a method, or
adding a new method. There is nothing that corresponds to this in XML.

The second consideration is to think about a document not just as an
object, but as the persistent state of a collection of linked,
collaborating objects. Of course this is an object too, but it plays an
interesting role that may be exploited with respect to compound documents.
The collaborating objects are the elements in the document. The state of
the object is captured in the element's attributes and content model. The
potential for collaboration is provided by relationships between elements.
XML supports composed relationships with the content model of an element,
and general associations through XLink and XPointer. So one way to think
about composite documents is to think of them as a collection of
collaborating objects (collaborations in UML) and how they might interact.
One way to view this is to treat each document as a domain of interest
where the collaborating objects contained in it enable some useful and
related set of activities. Then composing documents hooks these
collaborations together to enable some larger, composite set of activities.
By enabling activities, I mean providing state that can be manipulated
through DOM.

Finally, there is a difference between inheritance vs. delegation models,
and composition. Delegation can be done without composition by using a
link. Again, methods are needed to know what is being delegated through the
composition. XML only specifies the structure of valid data, not its
meaning. So by itself, it can only structure the composition, not say what
its for.



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

• Prev by Date: Compound Documents - necessary for success?
• Next by Date: Re: Why SAX needs namespace support
• Previous by thread: Re: Compound Documents - necessary for success?
• Next by thread: Re: Compound Documents - necessary for success?
• Index(es):
  • Date
  • Thread