Integrity in the Hands of the Client

[Howard Katz]

Mark, would you mind expanding just a bit on the following paragraph?
I'm not seeing what your point is:

	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.

Thanks,

Howard Katz

> -----Original Message-----
> From:	Mark Baker [SMTP:markb at iosphere.net]
> Sent:	Friday, November 21, 1997 9:08 AM
> To:	Joe Lapp
> Cc:	xml-dev at ic.ac.uk
> Subject:	Re: Integrity in the Hands of the Client
> 
> 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)

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)