[
Lists Home |
Date Index |
Thread Index
]
I work with a business consortium similar to what you describe as well as
for a vender implementing the standard.
The MISMO standards in the real estate finance industry (http://mismo.org)
are DTD based, and have most of the structures and data values optional. We
do require that the standard version be provided and if you are, for example
submitting a loan application that it has information about the Borrower.
The standards publications also have a 'Zero Delta' schema. This is a
schema that expresses no more constraints than those that can be expressed
in the DTD.
The idea is that the standard should provide a frame work for BtoB
communications. In our industry there are business contracts between
partners long before there are any transactions. No one wakes up in the
morning an says 'I think I will shop for a new provider of Credit Reports
today and direct all my traffic to them beginning this afternoon.'
MISMO also offers an MX Compliance program. This allows venders to certify
that they can produce minimal amount of required data and consume a payload
that has a maximal amount of information. For example all dates are required
to be in ISO 8601 basic format. That is not a constraint that the DTD can
test for. MX compliance does test for that constraint. Another example is
when sending information about an ARM loan means requiring information about
the index that determines the future rate. That information is not required
in the case of a Fixed rate mortgage. One MISMO design objective is "I'll
send what I have, you take what you need." As a producer of mortgage
application payload files I need to prove that I can produce index data when
sending an ARM loan application. As a consumer of loan application payloads
I need to prove that I can accept, without error, a fixed rate application
that has index information in it. Clearly a business level response in a
later step may reject doing a deal for that application.
Trading partners have differing business constraints. It is expected that
two venders of similar services will conditionally require different
information. Most venders have a certification process that proves that the
players can populate the MISMO structure with the business level data. The
industry has not yet evolved to the point of having a standard for
exchanging business constraints on the data. Now each vendor uses a
combination of non XML documents and spreadsheets to exchange those
constraints. Work is beginning on building a standard for that purpose.
I describe building MISMO standards based interfaces as equivalent to
building cables that connect electronic components. The goal is to deliver
the correct signal to the correct place. An interface may need to re-encode
a particular fact. For example coming from a system that does not use ISO
8601 date format or going to a system that does not use it one might need to
re-express the date in another form. In cable building you may need to do
something to match the impendence between the two devices being connected.
That is legitimate work for the cable and its electronic interfaces.
My rule of thumb for the boundary between interface logic and business logic
is "If the rule requires more than one fact it is business logic and belongs
in the business logic layer". By this rule it would be perfectly alright to
reject a message with a non ISO 8601 date. Since the partners have been
through a certification process that proved that we have agreed that they
should be that format, if I suddenly do not get a message that is not
something terrible has happened. On the other hand the constraint that the
birth dates of the borrowers must be more that 18 years before today takes
two facts, borrower's birth date and today's date. That message would not be
rejected and would be handed off to some down stream process.
Greg Alvord
smime.p7s
|
