Re: Summary of findings of TA Spec. review.

[duane <duane@xmlglobal.com>]

Rik:

While we have viewed your spec and know the work you are doing,  it is
still a point of procedure.  IT is impossible to say "Yes - the TRP spec
works for the ebXML infrastructure" when we don't "officially" know what
that is.

I think the work your group is doing is probably the only exception to
the rule but we also may be bitten by something later on. 

Let's discuss this further pending the reply from QR

We have no desire to stall any work.

Duane

Rik Drummond wrote:
> 
> we must have deliverables in Tokyo. so I believe it is important that
> assuming, which I assume it will, the trp ms spec passes the second round of
> reviews, then qr's review, that it go forward for vote in Tokyo irregardless
> of the state of the ta spec... best regards, Rik
> 
> -----Original Message-----
> From: duane [mailto:duane@xmlglobal.com]
> Sent: Saturday, September 23, 2000 5:01 PM
> To: tmcgrath@tedis.com.au
> Cc: Klaus-Dieter Naujok; Bob Sutor; Bill Smith; Ray Walker;
> ebxml-coord@lists.ebxml.org; ebxml-stc@lists.ebxml.org;
> ebxml-architecture@lists.ebxml.org
> Subject: Re: Summary of findings of TA Spec. review.
> 
> 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