[
Lists Home |
Date Index |
Thread Index
]
- From: Howard Katz <howardk@paradigmdev.com>
- To: 'Mark Baker' <markb@iosphere.net>
- 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
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@iosphere.net]
> Sent: Friday, November 21, 1997 9:08 AM
> To: Joe Lapp
> Cc: xml-dev@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@acm.org
> ICQ:5100069
>
> Will distribute business objects for food.
>
> xml-dev: A list for W3C XML Developers. To post,
> mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
> message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|