- From: Duane Nickull <duane@xmlglobal.com>
- Date: Thu, 03 Jan 2002 09:50:43 -0800
- To: David Orchard <dorchard@bea.com>
- CC: "'Roy T. Fielding'" <fielding@ebuilt.com>, "'Jeff Lowery'" <jlowery@scenicsoft.com>, "'Tim Bray'" <tbray@textuality.com>, www-tag@w3.org
David Orchard wrote: <SNIP> > One approach that I like is to think about the customer of the specification > and how many of them you expect to use the spec. ... > A final point is that sometimes you just can't make the spec simple as the > task is just too complicated. ><SNIP> To me these two points really emphasize the importance of collecting and documenting the requirements before writing a specification. ebXML did this and we ended up with a nightmare to write an architectrure for. The goal was to create an infrastructure that "enabled globally interoperability and the formation of ad hoc business relationships based on divergent XML vocabularies. It also must be capable of being fully automated". The related architectural document was only 40 pages and tied together a series of other specifications. This modular approach enabled (or should have enabled) a layperson to read each specification and understand it as a component. Each modular specification also made normative references to other protocols, themselves governed by specifications (examples: W3C schema, SOAP, HTTP, MIME). <sigh> It all seems so simple on paper ;-) Duane Nickull -- CTO, XML Global Technologies **************************** Transformation - http://www.xmlglobal.com/prod/foundation/ ebXML Central - http://www.xmlglobal.com/prod/central/
Received on Thursday, 3 January 2002 12:50:50 UTC