Lists Home |
Date Index |
- From: Mark Baker <email@example.com>
- To: Joe Lapp <firstname.lastname@example.org>
- Date: Fri, 21 Nov 1997 12:07:46 -0500 (EST)
On Fri, 21 Nov 1997, Joe Lapp wrote:
> In this posting I'm going to be a little bold and propose that both
> the XML and DOM specifications are flawed.
Bold's good. I like bold.
But I'm going to be just as bold and suggest that it is your use of
XML/DOM that is giving you problems, not the specs themselves.
>The existence of these
> flaws ride on the assumption that we care to use SGML/XML to create
> domain models for data where the data evolves over time.
Okay, so let's investigate how XML (and a couple words on DOM) are, IMO,
just fine for this.
> I'm also
> assuming that it is unacceptable for the client objects of a document
> to maintain the integrity of the document.
Amen. Once you've done encapsulation and data-hiding, there's no going back.
> Suppose we want to create a document that contains information about
> books and about the authors of those books, and suppose we require
> that whenever the document has a book, it also has information about
> the author of the book. The document will reside on a server, and
> one or more administrators will populate the document from their
> clients. Other users will be free to browse the document.
> We need to design the DTD for this document. Here is our first pass:
Ok, let me stop you right there.
A DTD is a fixed statement of structure. If you use one, you better be
darned sure that that structure isn't going to change anytime soon. As
we see from your example, you were struggling to define that structure
(as anybody would have given the same task).
So, what to do?
Go finer-grained. Ask yourself what doesn't change over time. In this
example, you know that you have books and authors. So why not give each
of those their own document type?
Furthermore, the relationship itself between a book and an author might
also be treated as a document type.
Sound too funky? Consider that that's exactly what is done in
loosely coupled structural OO work, or before that, first-normal-form
CORBA has the Relationship service for just this kind of functionality
for objects. Objects can create, destroy, type, and navigate directed
relationships at runtime.
Maybe for this example, it's a bit heavy-weight. I'm not sure. But
with just an author DTD, a book DTD, and XML-Links, you could get the
same job done - perhaps not quite as flexibly (since dependancies are
introduced within the documents themselves), but just as functionally
BTW, this is the same reason that a stream of serialized-to-XML Java
objects won't have a DTD. The structure of a set of objects is only
guaranteed to be known at runtime. But these streams will still be
> I have not been able to find a way to have the document server force
> clients to ensure that whenever they add a book, that book is
> associated with some author. Clients are given the responsibility
> of maintaining the integrity of the document.
The OMG's OMA has a place holder for a "Rules Facility" that does exactly
this. It allows arbitrary rules (including structural) to be hung off
the ORB as objects/documents, and the ORB is responsible for enforcing these
See, for example;
> The DOM model allows us to manage documents from a client, so long
> as clients assume part of the responsibility for maintaining object
> model constraints.
That depends who the 'client' is. If it's a traditional application,
then yes, that's bad. But it might be something on another "level"
(hopefully you'll understand what I mean by that by these examples),
such as a Rules Facility or Persistence service, in which case it's ok -
because their job is to maintain the internal integrity of the object.
>However, if we decide that the document server
> is responsible for maintaining these constraints, then the DOM
> model as it is currently architected will not suffice, since its
> document-update operations are not architected around transactions.
I don't see the need for two reasons. First, I would never use DOM
(or any other mechanism) to try and break the encapsulation of my
documents. Second, as I stated in my last message, transactions are an
overrated means of reasoning about distributed systems. They try and
make distributed processing look like local processing, when we now know
how impractical that view is.
Mark Baker, Ottawa Ontario CANADA. Java, CORBA, XML, Beans
http://www.iosphere.net/~markb email@example.com ICQ:5100069
Will distribute business objects for food.
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)