OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[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.


> Martin

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC