Re: 2.4.1 requirements document

[Nikola Stojanovic <nstojano@cjds.com>]

One of the things that TR&P group has discussed in their last meeting was an
issue of lightweight/heavyweight protocols and profiling:

<snip>
Identified need for lightweight and heavyweight protocols to support
different requirements. Had the idea of profiling usage of ebXML to support
different types of requirements.
</snip>

Nikola

----- Original Message -----
From: "Duane Nickull" <duane@xmlglobal.com>
To: "Peter Kacandes" <Peter.Kacandes@EBay.Sun.COM>;
<ebXML-Requirements@lists.oasis-open.org>;
<ebxml-architecture@lists.oasis-open.org>
Sent: Tuesday, March 07, 2000 4:30 PM
Subject: RE: 2.4.1 requirements document


<peterk>
I have a question with regard to section 2.4.1 of the document that makes
reference
to maintaining two apis, one for machines and another for people. This seems
to me
to be extroardinarily inefficient. It seems to me that there should be only
one API
to the system. If somebody wants to write a gui to the system, then they are
welcome to do it. I think it will be highly impractical to try and develop
and
maintain two apis. I have made these thoughts known within the architecture
group,
but am not aware that we came to any kind of conclusion on the topic.
</peterk>


Peter:

The two API's are absolutely necessary.  In an ideal world where everyone
has $250,000 to invest in a fully automated system and there are no errors,
ever, the machnine API may be able to be justified (I am not sure that
anyone could convince me).

Think of SME's.  They need a human window to the repository.  A lightweight
(read *simple*) human interface, maybe CGI based, will give them the
flexability to find the business objects they need without complex
infrastructure.

The human and Machnie API's are just that - API's.  They do not require any
extra overhead.  It is the application that provide the functionality.

There is also the concept of logic processing.  If the logic used is in any
way flawed,  you will not find the obejcts you need.  Imagine a case where
A->C is not available yet A->B and B->C exist.  This allows a mechanism with
Logic to now do A->C.  IF the logic is flawed,  the system will not work.

The API's are simplistic, lightweight and necessary.  We cannot exclude
SME's (or corporate Sweden <g>)from the ebXML infrastructure.

Duane Nickull