[
Lists Home |
Date Index |
Thread Index
]
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.
len
(my
opinion only. Not that of my employer.)
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?
| 