[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] Re: Core Components Specifications
Message text written by Sandy Klausner > Sally, Not so, "Amount Due" is derived data. A particular relationship between attribute values may be specified to remain invariant as part of the shared specification between trading enterprises. A processing engine should be able to dynamically test this invariant as a final integrity test before message shipment. The originating application that supplied the origin data cannot be relied upon to perform this test. So here is a case where agreement as to a specific constraint was declared at design time, but is dynamically evoked. Sandy <<<<<<<< Sandy, An alternate approach is to have two pieces of XML, one that defines the quantity "Amount Due" as a physical type (decimal, currency, etc), and then associated with this a verb script that defines how to calculate the result. A classic example of this is a HTML form with a field and then JavaScript to compute the value. The verb script may also simply point to say a URL where a webservice call returns the result. What this shows us is that we need to keep an open mind and an enabling infrastructure so that the implementation layer can marry to the logical model layer and critically the TWO should remain in synch' at all times via the registry. Being able to add multiple physical mechanisms pointing to a core component logical entity provides us with adaptable behaviour into peoples existing systems. Conversely - if I select "Amount Due" in the registry I should see the available physical methods associated to that for integrating that into my transaction. This then empowers the programmers to empower the business users. DW.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC