[
Lists Home |
Date Index |
Thread Index
]
Precisely, and it behooves the programmer to find
out what contracts will be in effect over a given
documented transaction. In some cases, the bits
on the wire are not author-driven or consumer-driven.
They are the document-in-transit and may be controlled
by a schema for that only. When authored, they are
authored to the local system requirements, may be
transformed for the in-transit document, and then
may be transformed again for the consumer's requirements.
This is one reason for pipelined processes and
orchestration/choreography.
In short, it may not be the case that one schema rules
all aspects of the information lifecycle. In my
experience, that is seldom the case where there
are several parties using that information. Of course,
that raises the stakes for PSVI systems and users
to be sure that data meets expectations. Processors
that silently alter these can cause trouble.
len
From: John Cowan [mailto:jcowan@reutershealth.com]
Jeff Lowery scripsit:
> A schema defines the intent of the author. If is so happens to coincide
> with the intent of the consumer, all the merrier.
Not necessarily. A schema may also indicate the requirements of the
consumer, to which the author must conform or else. Consider who is
the schema creator, and who is the author, the next time you fill out
some bureaucratic form or other.
|
