Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@i...] > Sent: Friday, November 21, 1997 9:08 AM > To: Joe Lapp > Cc: xml-dev@i... > 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@a... > ICQ:5100069 > > Will distribute business objects for food. > > 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...) 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...)
|
