Re: Summary of findings of TA Spec. review. my 2c

[duane <duane@xmlglobal.com>]

Jaideep:

THank you for your input.  At this point - we need to get this document
out so we can solicit specific feedback on what needs to be changed. 
There is a formal process for feedback and we need to release the
document before that can begin.  

The people who worked hard on this document are wanting to finsih their
work.  We require the plenary input before that can be done.

We look forward to your comments once our document has been approved for
release.

Duane NIckull

Jaideep Roy wrote:
> 
> Hi All,
> 
> I too agree that the document doesn't look like an architecture
> document from a software point of view. It needs some re-work and
> re-organization to be acceptable and to truely reflect all the hard
> work put in.
> 
> Regards,
> Jaideep Roy
> 
> --- Krishna Sankar <ksankar@cisco.com> wrote:
> > Hi all,
> >
> >       I agree with Duane in that the Architecture specification *is*
> > important
> > and is the foundation. So we do need one at Tokyo. We are software
> > professionals - we live and die by architecture.
> >
> >       As there are a lot of e-mails and some concerns, I dedicated this
> > Sunday to
> > analyze this document (to the best I can). Here are some of my
> > comments:
> >
> > 1.    Nagwa & Tim are referring to the version 0.8.71. I do not think
> > they are
> > referring to an old document. Is this the current version ?
> >
> > 2.    I do have to agree with Nagwa and Tim in the sense that this
> > document
> > does *not* read like an architecture document. But as I read thru the
> > document, it has a lot of information. The team has done a lot of
> > work and
> > it shows. But the document needs reorganization and more
> > material/diagrams
> > for a lot of sections.
> >
> > 3.    For example, the first detailed section should be the one which
> > describes
> > the ebXML architecture - what are the components at a high level, how
> > do
> > they fit in - some are layers like the business processes run on the
> > transport and some are orthogonal like the regrep. Some are
> > implementations,
> > some are concepts like the BP/CC, .... you get the picture.
> >
> >       For e.g.: Line 210: Talks about seven components. We should define
> > these
> > and give a brief description in 3.0. Something like "the ebXML
> > Architecture
> > is based on seven components viz. ..."
> >
> > 4.    We need a lot of diagrams explaining the ebXML Architecture - the
> > systems
> > overview diagram is over used; it is there everywhere. Even though a
> > common
> > diagram shows consistency, having only the common diagram does not
> > explain
> > much. The architecture diagram has to elaborate on this common vision
> > with
> > more text and diagrams.
> >
> > 5.    Many sections do not have a theme or worst some have multiple
> > themes.
> > Each section should do only one thing and it should do it well. (I
> > have
> > heard this many times from my books' editors - sometimes in not so
> > flattering words !)
> >
> > 6.    The Section 5 road map should be an Appendix. As it stands now, we
> > are
> > describing a roadmap without even covering what the components are.
> >
> > 7.    Yes, the document has a regrep-centric feel. It is because a lot
> > of the
> > sections talk only or talk much more about the regrep. We do need to
> > take
> > some stuff off and add more from other components point of view.
> >
> > 8.    The use cases are good. But we need to add more. Things like the
> > discovery, how to bootstrap a communication, etc are missing. I think
> > if we
> > look at each components and capture the most important use cases we
> > should
> > have them all.
> >
> >       Detailed and more elaborate use cases do belong to the respective
> > specifications. I am not sure about your point in the case of regrep.
> >
> > 9.    The use cases do need a taxonomy/categorization. Now it looks like
> > a list
> > of use cases without any relationship.
> >
> >       A diagram showing their relationships would help. The diagram can
> > also have
> > the 7 major components in the Y axis thus showing where each use case
> > fits
> > in. (I can draw a strawperson diagram)
> >
> > 10.   The sample files section is good. It needs a new name - may be
> > sample
> > documents is better or something much more generic. Here we run the
> > dichotomy problem. This document needs to be revised every time a new
> > sub-document comes out else this section will be outdated.
> >
> >       On second thought, the examples would not make sense without the sub
> > documents anyway.
> >
> > 11.   We do need a lot of sequence diagrams explaining the various
> > concepts,
> > interactions et al. Many of them belong in the use case section.
> >
> > 12.   That brings me to the use case section - do we need one ? It is
> > good, in
> > the sense that it describes what a minimum system should have. But it
> > adds
> > pages to the document and complexity.
> >
> >       I think if we judiciously select use cases which amplify the ebXML
> > architecture and explain the end-to-end process, develop good
> > sequence
> > diagrams and elaborate the relationships among the use cases, this
> > section
> > would do justice.
> >
> > 13.   We do need a section for various "shalls" and assumptions.
> >
> >       Now that I am an accessory ;-), I offer any help needed for all of
> > us to
> > get a good document out by Tokyo. As Duane said, with out an
> > Architecture
> > document, we cannot have the other documents.
> >
> >       cheers and have a nice weekend
> > ----------------------------------------------------------
> >        |          |             Krishna Sankar
> >       :|:        :|:            Member of technical Staff
> >      :|||:      :|||:           Internet Commerce
> >  ..:|||||||:..:|||||||:..       (Ph) 408-853-8475
> >     Cisco  Systems Inc          ksankar@cisco.com
> > ----------------------------------------------------------
> > "Failure is certain if we don't,
> >            but Success is uncertain even when we do.
> >                          So the choice is Ours, always..."
> > ----------------------------------------------------------
> >
> 
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/