Lists Home |
Date Index |
- From: Howard Katz <email@example.com>
- To: 'Mark Baker' <firstname.lastname@example.org>
- Date: Fri, 21 Nov 1997 09:16:31 -0800
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
objects won't have a DTD. The structure of a set of objects is
guaranteed to be known at runtime. But these streams will still
> -----Original Message-----
> From: Mark Baker [SMTP:email@example.com]
> Sent: Friday, November 21, 1997 9:08 AM
> To: Joe Lapp
> Cc: firstname.lastname@example.org
> 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,
> just fine for this.
> > I'm also
> > assuming that it is unacceptable for the client objects of a
> > 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
> Ok, let me stop you right there.
> A DTD is a fixed statement of structure. If you use one, you better
> darned sure that that structure isn't going to change anytime soon.
> 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
> example, you know that you have books and authors. So why not give
> of those their own document type?
> Furthermore, the relationship itself between a book and an author
> 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
> 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
> this. It allows arbitrary rules (including structural) to be hung off
> the ORB as objects/documents, and the ORB is responsible for enforcing
> 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
> overrated means of reasoning about distributed systems. They try and
> make distributed processing look like local processing, when we now
> how impractical that view is.
> Mark Baker, Ottawa Ontario CANADA. Java, CORBA, XML,
> http://www.iosphere.net/~markb email@example.com
> Will distribute business objects for food.
> xml-dev: A list for W3C XML Developers. To post,
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:firstname.lastname@example.org the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:email@example.com the following
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)