RE: 2.4.1 requirements document

["Duane Nickull" <duane@xmlglobal.com>]

<peterk wrote>
Duane,

I believe that you are mixing a number of different issues. Let's be clear
on the
distinction between the api to the system and the application that interacts
with
the api.
<peterk>

Have written many of these.  I am completely clear ont his topic.

<peterk>
Just because there is one api doesn't mean that you need to spend mucho $$
on some
automated system to access it.<peterk>

Are you trying to insinuate that writing a Soap based (or similar) client
interface, installing it and passing the automated responses to handler
routines is within the scope (not to mention budget)of all SME's?  The
complexity is precisley why EDI failed to scale.  I have personal experience
as the owner of an SME.

<peter>
Let's take a particular example. Suppose the api has a call
ServiceGetBusiness.
This call returns all business that provide a particular service. Why should
there
be two versions of this call in the api depending on whether or not it is
being
called by another machine or by a person using some gui into the
reg-rep?</peterk>

Uhhh...  if they are being called in two *Completely* different protocols,
and require completely different responses, don;t you think that would be a
distinguishing factor?

Take for example a SOAP message to perform an RPC on a repository.  The
client opens a socket and fires a saop message to a prot directly on a host.
The RPC then fires a query (encoded in XML with no stylesheet) back to the
client.  That is fundamentally different than a CGI based (IE - less
controlled environment) interface.

<Peter>In the case of a machine calling it, the automated system might then
take the
returned information and do further processing with it such as search eash
business
to also find out which ones support ofx for processing payment for the
service.</peter>

I don't think this is a practical approach.  You are talking automatic
functionality in an application.  Who is going to write this for the SME's
and still make it affordable.  I agree that enterprise level customer will
probably have this but SME's???

<peter>
In the case of the human, they might use the GUI to browse the list of
returned
businesses and decide to do something further.

The point being that it is the responsibility of the GUI to handle the
interaction
with the system so that a human, whether they are at mondo corp or mom&pop
llc can
do something with it, but the calls to the system (the api) is the same and
there
is only one of them.</peter>

No.  They are not the same API.   They use totally different processes for
I/O and have totally different requirements for transportation, security and
functionality.  It's like comparing line command arguements to a GUI in a
program.  The line command arguments will not usually refturn a graphical
display.  They usually return text only.  The GUI, on the other hand returns
the pretty boxes and graphics that many Windows TM users are used to seeing.
They are architecturally totally different mechanisms.  The commonality ends
with the fact that they both speak to the application and can communicate
input and intepret output.

<peter>If mondo corp wants to spend big bucks on a system which totally
automates
interaction with the api and integration into their back end systems, then
they are
more them welcome to do it.

If mom&pop llc wants to download some aplet that helps them to formulate
queries
and has some built in style sheets to format the output into whatever html,
then
that is there business.</peter>

This essentailly agrees with the need for two interfaces - one human and one
machine.

<peter>The case of error handling is the same. The logic you refer to is all
on the client
side and is not part of the api. The system will report whatever errors it
is going
to report. The automated system will have the logic to do whatever it needs
to do.
In the case of the gui, it will report the error and its up to the human
user to
decide what to do next and the client application, depending on its
sophistication,
might have varying degrees of logic built into it to assist the user with
error
handling. In the most simplistic gui, the user might just get back a cryptic
error
message (not unlike a 404 page that you see in your prowser). If the user
shells
out for a more sophisticated client, it will have more capability to
interpret the
error and direct the user as to what they might want to do next.</peter>

An error reporting to STDOUT or ERROUT is definately not the same as an HTTP
"404".  How will an error going to STDOUT be intepreted and directed to HTTP
as an HTML encoded error message?  This is done server side,  not client
side.  A browser cannot detect and internal error.  It can ONLY accept
errors from the daemon it is communicating with.  NCSA architecture is very
clear about this.  For security purposes,  you cannot allow all errors to be
avaiable to whoever requests them.

<peter>
There are all kinds of other reasons for the single api approach, also.
Suppose,
for example, you try to take a whack to doing the human api as part of the
system
itself, then people are stuck with that output even if it doesn't meet there
needs
so you are stifling the creativity of all of those people out there who
would like
to do all kinds of different things with it. Nobody will be happy with it
and
you'll be stuck with endless modifications trying to glom on different
things to
try and satisfy folks.</peter>

Okay,  just to demonstrate that both can (and do) exist side by side,  go to

http://www.goxml.com

The index page will allow a human search.  This will cause a query to be
performed.  But - suppose you do not want the html encoded results becuase
you cannot manipulate them.  That's okay,  we have another tool (a machine
API) at:

http://www.goxml.com/xqi.htm

This will allow queries in the form of XML streams and return results as XML
streams.

This clearly demonstrates two different API's for submitting queries and
receiving responses.  They are both fundamentally different and have
different requirements.

Thank you for your comments -

Duane Nickull