Re: 2.4.1 requirements document

[Mike Rawlins <rawlins@metronet.com>]

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/