OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] U.S. Federal Goverment's Data Reference Model (DRM)XML Sch

[ Lists Home | Date Index | Thread Index ]
  • To: Michael Kay <mike@saxonica.com>
  • Subject: Re: [xml-dev] U.S. Federal Goverment's Data Reference Model (DRM)XML Schema
  • From: "J.Pietschmann" <j3322ptm@yahoo.de>
  • Date: Tue, 21 Jun 2005 22:48:35 +0200
  • Cc: xml-dev@lists.xml.org
  • User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/

Michael Kay wrote:
> The problem is that messages exchange information about a
> business object, and different messages exchange different subsets of the
> information.

It may be even much worse than that.
a) a message may lump together attributes of different business objects
b) a message may contain data from multiple business object instances
c) a message may contain aggregated data from various business objects
  (of the same class or different classes), which forces either
  willy-nilly extensions to the already complex business object zoo or
  dealing with data which is *not* an attribute of any business object...
As an example: the answer message to "get customer credit and risk data"
which returns credit limits from various accouts of different types the
customer might have, partly aggregated by risk class, as well as the
net security worth backing part or all of the risk.
Telling the designers to make several requests, one for each object, and 
aggregate in the client has already been proven to be a bad idea.

My conclusion: design objects and message separately, and use a tool
to check whether they fit together.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS