Integrity in the Hands of the Client

[Mark Baker]

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 
entity/relationship schemas.

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

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

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

See, for example;

http://www.jeffsutherland.org/oopsla97/rouvellou.html

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

MB
--
Mark Baker, Ottawa Ontario CANADA.                Java, CORBA, XML, Beans
http://www.iosphere.net/~markb               distobj at acm.org  ICQ:5100069

   Will distribute business objects for food.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)