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

[ Lists Home | Date Index | Thread Index ]
  • To: "Michael Kay" <mike@saxonica.com>, <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] U.S. Federal Goverment's Data Reference Model (DRM) XML Schema
  • From: "McNally, David" <David.McNally@moodys.com>
  • Date: Wed, 22 Jun 2005 12:33:56 -0400
  • Thread-index: AcV2jzGel4js/X3mQRSj/Czll4SQHQADMOYgACrZ0cA=
  • Thread-topic: [xml-dev] U.S. Federal Goverment's Data Reference Model (DRM) XML Schema

Title: Message
Bob DuCharme did some work on deriving different schemas from a main schema depending on what point you were at in a process, and perhaps a similar approach could be used for messaging. 


But it might be hard to manage for many different message types.


-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com]
Sent: Tuesday, June 21, 2005 4:11 PM
To: 'Chiusano Joseph'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] U.S. Federal Goverment's Data Reference Model (DRM) XML Schema

I'm interested in how you tackle the problem of translating from business object definitions into message definitions. I'm working with an organization that has designed schemas to represent its (many hundreds of) business objects, and is now struggling with the question of how to design messages for application data interchange that are based on these object definitions. The problem is that messages exchange information about a business object, and different messages exchange different subsets of the information. Making all the information mandatory and thereby forcing the sending application to populate the message with data that the recipient doesn't want to know seems unproductive; equally, making all the data optional seems to defeat the purpose of validation. So it seems that one needs a message definition (=type) for each message that is somehow related to the schema for the business object, but isn't related to it by one of the recognized mechanisms of restriction and extension. It needs some kind of concept of being "derived by projection". 
Any thoughts or advice?
Michael Kay

From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: 21 June 2005 19:30
To: xml-dev@lists.xml.org
Subject: [xml-dev] U.S. Federal Goverment's Data Reference Model (DRM) XML Schema

The XML Cover pages just announced[1] the availability of a draft XML schema[2] for the U.S. Federal Goverment's Data Reference Model (DRM) initiative. I am posting this here to invite comments from the broad XML community as to our approaches for this initiative. A specification for the DRM XML Schema is at [4] (includes all elements/attributes, their definition, and hyperlinks for efficient navigation).
I presented[3] on this schema at last week's First Quarterly DRM Public Forum along with Mike Daconta (U.S. Department of Homeland Security Metadata Program Manager), who is leading this vast interagency effort. We discussed the design factors that we took into account regarding the schema, use of existing open standards, and other aspects.
If you have comments or questions, please feel free to (a) submit them per the instructions in [1], (b) express them directly to me, or (c) express them here on the XML-DEV listserv.
(DRM XML Schema)
(Presentation on DRM XML Schema)
(DRM XML Schema Specification]
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com


The information contained in this e-mail message, and any attachment thereto, is confidential and may not be disclosed without our express permission. If you are not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution or copying of this message, or any attachment thereto, in whole or in part, is strictly prohibited. If you have received this message in error, please immediately notify us by telephone, fax or e-mail and delete the message and all of its attachments. Thank you.

Every effort is made to keep our network free from viruses. You should, however, review this e-mail message, as well as any attachment thereto, for viruses. We take no responsibility and have no liability for any computer virus which may be transferred via this e-mail message.


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

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