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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-coord message

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


Subject: Re: Summary of findings of TA Spec. review.


Yesterday the Executive in its conference call reviewed the
material and recommendation from the QRT in regard to the ebXML
Technical Architecture Specification.

The Executive supports the recommendation to not go for public
review at this time.  In addition the Executive is currently in
the process to identify some resources to help the Architecture
Team in its task to address the issues raised in order to ensure
timeline that is allows the document to go for review as soon as
possible. We hope to present those resources to the team by next
week.

Regards,

Klaus

On Thu, 21 Sep 2000 08:08:00 +0800, Tim McGrath wrote:

>Please find below (and attached ) the summary of our issues with the TA
>Specification.
>
>More detailed notes are available on request to the QR Team.  We welcome
>the opportunity to assist with clarification on any of these issues.
>
>
>--------------------  START OF DOCUMENT ---------------------
>ebXML Quality Review Group
> Summary of Review of
>ebXML Technical Architecture Specification
>Version:  (0.8.71) Release Date:  13/9/2000
>
>Report Prepared: Sept 20, 2000
>
>Edited by:  Nagwa Abdelghfour and Tim McGrath
>
>Key points why we recommended this document not go for public review:
>
>* This document does not define an Architecture  - where each of the
>components of the system and their interactions or interface points are
>clearly defined and put in context.  In some cases it tries to be a
>Requirements Document and others a Design Specification.   For example,
>it should not get into the details of the design of components (as in
>the RegRep section).  That should remain with the respective project
>team.
>
>* Lacks HIGH-LEVEL Use Cases for the operability of ebXML compliant
>applications.  In addition, the Use Cases are not complete in that they
>fail to show the flow of actions.
>
>* The document is uneven, dealing with minutiae in some areas and making
>generalisation elsewhere.  For example, it is too focused on RegRep at
>the expense of other issues.
>
>* Editorially, there are sections that are either unnecessary or
>unorganised or unclear.  We would expect the final document to be more
>concise than this (ie. 83 pages).  In addition, some sections appear
>incomplete and contain several "... to be discussed later ...", "...TBD
>...", "... see section zzzz ...", etc.  This indicates the immaturity of
>the document.
>
>Some of these points may be acceptable in isolation but reflect the need
>for further development.
>
>More importantly, some points were raised at the previous document
>review in San Jose and then subsequently by team members   yet they
>still appear in this document.  This may indicate an endemic problem
>with the document s development processes rather than a systematic one
>in the approach used.
>
>--------------------  END OF DOCUMENT ---------------------
>
>--
>regards
>tim mcgrath
>TEDIS   fremantle  western australia 6160
>phone: +618 93352228  fax: +618 93352142
>
>

--
Klaus-Dieter Naujok                        NextERA Interactive
Antioch, CA USA                                +1.925.759.1670

PGP Finger: 6A4B 1683 CD99 E7BE F855  CC2F 4569 6BD8 76BD 1117




[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