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 Sc

[ Lists Home | Date Index | Thread Index ]

Len, please see comments below marked with [JMC].
 
Joe
 
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 


From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
Sent: Tuesday, June 21, 2005 4:28 PM
To: 'Michael Kay'; Chiusano Joseph; xml-dev@lists.xml.org
Subject: RE: [xml-dev] U.S. Federal Goverment's Data Reference Model (DRM) XML Schema

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.   
 
[JMC] Although the term "standardization" is broad, we will be standardizing exchange packages in that they will be represented according to the DRM metamodel. Not sure what you mean by "reference packages" and the "reference level" - is this synonymous with "federal"?
 
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.   
 
[JMC] Would be happy to hear more about these technical reasons, and why RDF is a non-starter (note that we only use rdf:id in the DRM XML Schema).
 
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.
 
[JMC] I should clarify that the NIEM is a joint effort between DHS and DOJ, it's not solely a DHS initiative.
 
Joe (end of comments)
 
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. 
 
len
 
(my opinion only.  Not that of my employer.)

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




 

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

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