Re: Summary of findings of TA Spec. review.

[Murray Maloney <murray@muzmo.com>]

For what it is worth, I agree with Rik on this.
I do not agree with Duane's assertion that the 
ebXML architecture is currently undefined simply
because the document is not ready for prime time.
In fact, I am almost certain that the sun will 
continue to rise while we await an architecture spec.

At 02:18 PM 9/24/00 -0700, duane wrote:
>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
>
>
>