Re: Summary of findings of TA Spec. review.

[duane <duane@xmlglobal.com>]

Tim:

TIm - this is just a re-edit of Nagwa's comments - which she has since
admitted are based on comments she heard at San Jose.  The document
submitted to your team is completely new and has no ties to the San Jose
Document whatsoever.  We address each and every one of these comments
after San jose.

TO the Steering Committee:

All other work by the QR team needs to be put on hold.  THis is a point
of procedure.  They cannot approve drafts by other teams without knowing
how that work fits into the ebXML architecture!!!!  Will the work meet
the needs of the ebXML architecture???  HOw can the POC team begin to
sanction work without knowing how that work will sit with the ebXML
infrastructure??

I suggest that the QR team gives the TA document 100% focus.  If it
means going through it with us one line at a time - so be it.  We are
not attached to the current document.  We ARE committed to ebXML being
completed and meeting the needs of those who will use it.  

This reply below is not what we need. The person who wrote this did not
read the correct document.  Please see the subsequent message about
sending a properly defined list of shortcomings.

See comments in line:


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

Each section has a very clearly titled section doing this.  It reads
"Functional Requirements".  If some specific detail is missing,  let the
plenary tell us what it is.

>  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.
It is not the design we specify expect in the case of the decentralized
repository model - something which strangley enough was mirrored by UDDI
and eCo.  I think that it warrants merits and should stay in.  IF reg
rep want it out, let the comments come from the appropriate people who
work with that.

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

THis is not true - the high level use cases are highly detailed in
Appendix "A".  If you feel some aspect of the use case is missing -
please be very specific.  THis is complete enough to actually design
software applications on. (I know becuase some of the people who work at
XMLG have done this and they haven;t had to ask for anything to be
clarified.)  IF the person commenting read the document, they would have
seen these at the end.

> * 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.
THat is one comment which Nagwa has admitted she heard in San Jose -
referring to an old (and depracated) version of our draft.  I would like
some specific examples.

> * 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.
Yes - I agree however, this is insufficient to hald it back.  These are
minor typos and can be fixed in about one hour.

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

THere was no document review in SAn Jose.  We have submitted this
document for the first time last week.  THe document being discussed in
San JOse bore no resemblance to the current work.  Since we have not
submitted this document, how can your statement be?   

Solutions:

I suggest that one of your people spend time going through the TA spec
line by line and commenting where it you feel we should change this.  We
don't take any offense to criticism, especially where it is deemed
constructive.  PArt of the ebXML process is to solicit this feedback in
an open manner.  However, we cannot allow generalised comments to hold
back a problem which we believe doesn;t exist.

PLease respond to our team list ASAP so we can get our work done.

THank you 

Duane Nickull

> 
> --------------------  END OF DOCUMENT ---------------------
> 
> --
> regards
> tim mcgrath
> TEDIS   fremantle  western australia 6160
> phone: +618 93352228  fax: +618 93352142
> 
>   ------------------------------------------------------------------------
>                                    Name: EbXML-QR-TA-Review-Sep20.doc
>    EbXML-QR-TA-Review-Sep20.doc    Type: WINWORD File (application/msword)
>                                Encoding: base64