Re: Summary of findings of TA Spec. review.

["agrangard@nycall.com" <anders.grangard@edifrance.org>]

Dear Colleagues,

It has been my understanding since Orlando all the way through the latest
San Jose meeting that the principles of the TechArc specification are good
and accepted. We do receive comments, most of them very good ones, both
within the team and outside, which is normal and indeed necessary to
progress the document. However, since many of these comments are
contradictory (we want more details/we want less details etc) it takes some
time to work them into the document. I would thus ask you to urgently point
out where we have gone astray, as requested by Duane, or circulate the
document to the ebXML community for comments.

Regarding the voting process, the document was circulated to the team and
voted unanimously at the subsequent conference call.

And finally resources. All new members are of course welcome, whether they
come from the executive team or elsewhere

Kind regards
Anders Grangard

----- Original Message -----
From: Rik Drummond <rvd2@worldnet.att.net>
To: duane <duane@xmlglobal.com>
Cc: <tmcgrath@tedis.com.au>; Klaus-Dieter Naujok <knaujok@pacbell.net>; Bob
Sutor <sutor@us.ibm.com>; Bill Smith <bill.smith@sun.com>; Ray Walker
<raywalker@attglobal.net>; <ebxml-coord@lists.ebxml.org>;
<ebxml-stc@lists.ebxml.org>; <ebxml-architecture@lists.ebxml.org>
Sent: Monday, September 25, 2000 1:59 AM
Subject: RE: Summary of findings of TA Spec. review.


> we new that when we started the parallel efforts in the beginning we would
> have sequencing problems.... so it is not the best, way to go, but it is
an
> appropriate way to go. we must have a deliverable in tokyo.... that is
what
> we are pushing for on  the trp ms spec.... best regards, and me know if i
> may be of support on the ta spec...
>
> -----Original Message-----
> From: duane [mailto:duane@xmlglobal.com]
> Sent: Sunday, September 24, 2000 4:18 PM
> To: Rik Drummond
> Cc: tmcgrath@tedis.com.au; 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.
>
>
> 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
>
>
>