[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: U.S. Federal Goverment's Data Reference Model (DRM) XML Sc

fea drm niem
I see this in GUI design where the GUI is made to represent the absolute space of
all of the information required rather than answering the first questions of the GUI:
who, what, when, where and sometimes why.
Information space does not equal time and intention.   It is easy to spot a GUI
developed without answering those questions because the user gets lost in
space fast.
The answer, anyway, to Joe's questions will be in the development of the
IEPs (Information Exchange Packages) at both the reference and the
local agency level.  I expect that to occur as a result of RFP processes,
not standardization although standardization of the reference packages
will be very useful.  I don't expect the FEA to be adopted any time soon
for technical reasons including the application of RDF within them.  RDF
is a non-starter.  I expect Daconta's NIEM's work to get rapid uptake
once they get past the pilot stage and the modularization of GJXDM is
accomplished such that the local agencies can cite them in RFPs.
No contract == no messages.   The devil of the DHS/DOJ work is too
many separate efforts are being harmonized and that takes too much
time and energy given the separate loci of control.  It will take some
very hard nosed managers to keep it from being a CALS redux
because the consultancy feeding frenzy is fully on.   So from where
I sit, the IEPs are where the results will be had.  Reports are easy
to understand. 
(my opinion only.  Not that of my employer.)

From: Michael Kay [mailto:mike@s...]
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?


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.