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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-requirements message

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

Subject: Re: 2.4.1 requirements document

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.


Matthew MacKenzie

-----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-architecture@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

>Sorry I didn't step in sooner, but could we please get back to reality
>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
>Program Interface [API]) and one for humans (manual HyperText Transfer
>[HTTP]).  "
>to something like:
>"This registry should support human interfaces (such as browsers) as well
>direct interfaces by applications."
>Please frame further comments in this light.  If you want to continue to
>the technical details, please work them in the appropriate project teams
>take the requirements project team off of the distribution.
>Duane Nickull wrote:
>> <scott>
>> The "human interface" is not classified as an "API" per se, but rides on
>> 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
>> the actual costs for SME's.
>> All I am really proposing is that we create the two interfaces - the API
>> 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
>> 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

[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