[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Party XML Schema Defintions
Martin Bryan wrote: ... > No, No, No. You should not need to refer to the registry from every message. > Message types are linked to the registry, not message instances. >>>>>> Martin - I know, it was myself who fought hard to include this in the ebXML Architecture. > Information > that is instance specific should remain a part of the message. If as a part > of message validation you want to check that the message contents match the > CPP contents then you do a match, using XSLT, >>> Please be careful here. Use of XSLT is not a requirement for ebXML nor would it likely be the preferred methodology for conducting XML to XML transforms. XSLT uses several procedural coding methodologies like conditional statements and looping constructs. It may be nearly impossible to create XSLT teanformation documents dynamically based on a Semantic reference. It is more likely that a declarative approach will lend itself to easy dynamic transformation template creation (eg - fully automated transformations, the holy grail of interoperability). > between the contents of one > element in the instance with the contents of the referenced CPP document. > You do not expect the data required by the user to be taken from the > registry because you cannot guarantee access to it will not be denied at a > critical time. >>>>>>>>>>> This has never been advocated that a Trading Partner must query into a Registry each time they use a document referenced by the Registry. Local Caches and industry standards already in use will mitigate most needs for Query/retrieval. Going to the registry, then retrieving docs from somewhere else simply won;t scale. We are in complete agreement that it is not feasable. CPA also has a mechanism for reusing the same CPA for subsequent transactions. Marty and the team specifically engineered it so it is reusable - a very desirable feature. As far as the Registry not being available, - it is possible that the Registry could fail at any time however a federated model of multiple distributed registries will provide redundant systems. A single Registry is a single point of failure - something that is explicitly forbidden by the Technical Architecture of ebXML. Cheers Duane > Martin
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC