RE: 2.4.1 requirements document

[Peter Kacandes <Peter.Kacandes@EBay.Sun.COM>]

I feel that the requirements for human interfaces will be so diverse that all that 
you will wind up accomplishing is that nobody will be satisfied and many people 
will be quite unhappy. It seems to me that that is beyond the scope of of our 
activity.

The beauty of developing the api and leaving the human interface open is that you 
open the floodgates of creativity such that all kinds of people will then be free 
and engaged in the activity of developing the broad spectrum of client interfaces 
that meet the needs of particular communities which could never be anticipated much 
less addressed by ebxml.

I don't think its a cost issue for SME's. On the contrary, by leaving the human 
interface open to developers, you assure that there will be many different 
solutions at all different price points. The SME can then decide which one best 
suits their needs.

It's a fallacy to think that they are all going to develop their own clients. Most 
likely 99+% will purchase an off the shelf client that fits their needs.

At least thats my take on it.

regards

pk

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

Peter Kacandes

Application Planning, Architecture & Strategy	phone number: 	X36529
WWOPS IT/Supply Chain Management		email:	peter.kacandes@ebay