Re: 2.4.1 requirements document

["Matt MacKenzie" <matt@xmlglobal.com>]

Mike, all:

>From my perspective, (that of a person who designs *interfaces*), I like
your re-phrasing because it leaves the door wide open for an extended family
of interfaces, but the more sensible side of me says that maybe the old
wording is better because it nails down HTTP as the transfer protocol.  HTTP
is an excellent choice for reasons most people on these lists should know,
and deciding on it now may save time later.

Regards,

--
Matthew MacKenzie
CTO/VP R&D XML Global

-----Original Message-----
From: Mike Rawlins <rawlins@metronet.com>
To: Duane Nickull <duane@xmlglobal.com>
Cc: Nieman, Scott <Scott.Nieman@NorstanConsulting.com>; Peter Kacandes
<Peter.Kacandes@EBay.Sun.COM>; ebXML-Requirements@lists.oasis-open.org
<ebXML-Requirements@lists.oasis-open.org>;
ebxml-architecture@lists.oasis-open.org
<ebxml-architecture@lists.oasis-open.org>; ebxml-regrep@lists.oasis-open.org
<ebxml-regrep@lists.oasis-open.org>
Date: Tuesday, March 07, 2000 5:03 PM
Subject: Re: 2.4.1 requirements document




>Folks,
>
>Sorry I didn't step in sooner, but could we please get back to reality
here?
>This document focuses on requirements, not on design and implementation.
>Perhaps the statement in 2.4.1 is too specific and should be more general.
>
>Does anyone object to changing it from:
>
>"This registry should have two interfaces - one for applications
(Application
>Program Interface [API]) and one for humans (manual HyperText Transfer
Protocol
>[HTTP]).  "
>
>to something like:
>
>"This registry should support human interfaces (such as browsers) as well
as
>direct interfaces by applications."
>
>Please frame further comments in this light.  If you want to continue to
discuss
>the technical details, please work them in the appropriate project teams
and
>take the requirements project team off of the distribution.
>
>Cheers,
>
>Mike
>
>Duane Nickull wrote:
>
>> <scott>
>> The "human interface" is not classified as an "API" per se, but rides on
top
>> of the registry and repository API.</scott>
>>
>> You are correct.  API does infer Application interface.
>>
>> <scott>Java servlets, Perl and/or XSL could
>> formulate the HTML to XML API transformation, and simple client/server
>> technology (sockets, HTTP, etc.) could pass the data to the Registry.
>> Requests to the registry could be passed on to the Repository as a proxy
>> service to retrieve repository contents.</scott>
>>
>> This method still carries extra overhead for the client in terms of
>> development.  I have received numerous communiques indicating a concern
for
>> the actual costs for SME's.
>>
>> All I am really proposing is that we create the two interfaces - the API
and
>> the human interface.
>>
>> Writing a human interface for an XML context search is not a task to be
>> taken lightly.  There are very few of these anywhere in the world and it
>> takes some very special know how.  We (goxml.com) tried 4 or 5 before we
got
>> it right.   I think that in the interest of KISS (from the users'
>> perspective), we should build this functionality into the architecture.
>>
>> Duane Nickull
>
>--
>Michael C. Rawlins, Rawlins EDI Consulting
>http://www.metronet.com/~rawlins/
>
>