RE: latest Version

[Scott Hinkelman/Austin/IBM <srh@us.ibm.com>]

David W.,
I saw your post. I believe there is a problem in the flow.
What ever case, "final" steps should be the flows marked
8->9->12, so there is some problem. This is sending a
propsed CPA and perhaps negotiating then doing business.

What ever the problem (or disagreement ?),
I would suggest at this time we simplify the diagram and the
discussion away from detailed discovery flow. (We had some
interesting discussion last week on this in NY and there is
much to flatten). I say we just
indicate a query to the RegRep for who supports a specific
BusinessCollaboration and which CommercialTransactions
using the advertised CPPs registered by Partners,
and then conduct 8,9,12.

So, for architecture, I say we drop 10 and 11 and rename
12 to 10. Label 6 as "query over CPPs", and label 7
as "return results". And keep it at that level.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074

---------------------- Forwarded by Scott Hinkelman/Austin/IBM on
10/16/2000 02:26 PM ---------------------------
Scott Hinkelman
10/16/2000 01:49 PM

To:   Brian Eisenberg <BrianE@DataChannel.com>
cc:
From: Scott Hinkelman/Austin/IBM@IBMUS
Subject:  RE: latest Version  (Document link: Scott Hinkelman)

<Line 203 - show stopper>
Are steps 8,9 and 10,11 swapped? How would Partners agree on TPA if they
don't know Business scenarios (and which ones to choose).
</Line 203 - show stopper>

>>>>I will get clarification on this from Klaus and David, as they were
primarily responsible for this section.


Dont bother. Nikola is correct.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Brian Eisenberg <BrianE@DataChannel.com> on 10/16/2000 01:37:30 PM

To:   "'Nikola Stojanovic'" <nhomest1@twcny.rr.com>, ebXML-Architecture
      List <ebxml-architecture@lists.ebxml.org>
cc:
Subject:  RE: latest Version



>>>>Comments below

-----Original Message-----
From: Nikola Stojanovic [mailto:nhomest1@twcny.rr.com]
Sent: Sunday, October 15, 2000 11:14 AM
To: ebXML-Architecture List
Subject: Re: latest Version



<Line 53 - important>
Sort Participants by LastName.
</Line 53 - important>

>>>>Done.

<Line 53 - very important>
Add 2 more Participants: Dick Brooks - Group 8760 and Henry Lowe - OMG.
Also, I don't have the name of the 4th member of our SJ team who worked
with
us on MS section.
</Line 53 - very important>

>>>>Done.

<Line 63>
Change FirstName from Nicola to Nikola.
</Line 63>

>>>>Done.

<Line 99>
Just by looking at TOC, CC section looks very thin. Should secs 18 and 19
be
under the same supersection?
</Line 99>

>>>>We need to get some feedback and a status update on what's going on
within CC right now. My understanding is that they are jointly working with
BP on the Collaboration MM and UML Model document.

<Line 173 - show stopper>
It is very important to make it clear that ebXML is not "whole or nothing"
approach and that it would be possible to use just some of ebXML aspects
that suit a particular Business. This is an architectural issue and it
might
be very important for early adopters as well. We've discussed this issue
before and I hope we agree that there are different paths and possibilities
for Businesses to adopt ebXML.
</Line 173 - show stopper>

>>>>Nikola - are you referring to chapter 7.0? I agree that we need to
discuss this issue in our doc, but am not sure where you are suggesting we
add it. Perhaps you can come up with a paragraph that elaborates on this
issue.

<Line 203 - show stopper>
Are steps 8,9 and 10,11 swapped? How would Partners agree on TPA if they
don't know Business scenarios (and which ones to choose).
</Line 203 - show stopper>

>>>>I will get clarification on this from Klaus and David, as they were
primarily responsible for this section.

<Line 226 - show stopper>
This very important step is not represented in figure 1. I think it should
be.
</Line 226 - show stopper>

>>>>Ditto for your comment re: line 203

<Line 288>
AFAIK, we have not discussed "Open-edi" so far in TA, and I need some time
to digest it. Anyway, whole section is very heavy on "Open-edi" and doesn't
mention any other initiatives.
</Line 288>

>>>>We discuss open-edi, to set the stage for explaining the ebXML
architecture in terms of the Busines Operational View and the Functional
Services View. This distinction effectively separates the discussion of
busines view of ebXML from the functional view.

<Line 430 - very important; almost show stopper>
Figure 5 contains: Registry Service Interface and Business Service
Interface. There is no Messaging Service Interface. This interface is so
important that it should be represented in this View, as suggested in
section 10.
</Line 430 - very important; almost show stopper>

>>>>I Agree - We will do our best to figure out the best way to represent
the MS interface in the diagram.

<Line 441 - very important>
We have already discussed the issue of UUID/GUIDs several times and I would
not bring it up again. I would imagine that RR people would be the ones who
will have some comments related to this if it is not in synch with their
spec. I would suggest that we just add "Globally ..." qualifier to this
entity.
</Line 441 - very important>

>>>>We have abstracted back from both GUID and UID and are now referring to
them simply as UIDs (Unique Identifiers). We will work to ensure that we
are
in sync with the RR team on this issue. I agree that it may not be
appropriate to discuss UIDs in this section. Perhaps we should move to RR
section. We will discuss and take the appropriate action.


<Line 531,542 - very important; almost show stopper>
Again, MS - Messaging Service is not represented even though it is
mentioned
in some places.
</Line 531, 542 - very important; almost show stopper>

>>>>Our intentions with the diagrams are to show the various phases showing
the interaction between various components. I agree that we should figure
out a way to show that the MS is responsible for sending/receiving
messages.
We will discuss and take this appropriate action.


<Line 594 - very important; almost show stopper>
Up to this point, doc has not addressed the issue of "ebXML Modularized"
and
it should have. It doesn't show "ports" of components and how would ebXML
adopter choose what components / packages are needed for her/his own
Business.
</Line 594 - very important; almost show stopper>

>>>>This is similar to your comments above (line 173). I agree that we need
to make it clear, but we don't want to get into implementation specific
details. Specific implementation requirements, as we learned from our last
TA spec version, are beyond the scope of the architecture.

<Line 625 - show stopper>
Do we store ebXML Metamodels in ebXML Registry or ebXML Repository? Also
the
concept of Repository needs to be defined properly, IMO (previous section).
</Line 625 - show stopper>

>>>>Metamodels are stored in the repository and queried via the registry.
We
will be sure to clarify this distinction.

<Line 632>
We need to clarify what we mean by XML Schema.
</Line 632>

>>>>I agree. Perhaps we should change the diagram (Figure 9) to XML
Representation instead of XML Schema.

<Line 801 - show stopper>
We should not call the upper layer "Transport Layer". There are many other
aspects in this layer so I wouldn't use this name.
</Line 801 - show stopper>

>>>>Hmmm... Any suggestions on an alternate name???

<Line 964 - show stopper>
Please put back the graphics from the draft version of TR&P section, which
was posted on 10/3/2000. Current ones seem to be corrupted (do not show
everything).
</Line 964 - show stopper>

>>>>The diagrams were revised to make them more readable in print format.
Furthermore, the comments posted to the list by Chris Ferris
(http://lists.ebxml.org/archives/ebxml-architecture/200010/msg00016.html)

<Line 1125 - very important>
Once more, some Usages that show "ebXML Modularized". Like, I have
Messaging
Service spec and I don't care about the "Whole Thing". How can I use just
MS
piece and do some Business with someone else. Is this a valid Usage of
ebXML? I would say yes, and I think we need to show some of those "Minimal
ebXML" kinds.
</Line 1125 - very important>


<General - very important >
We need to accompany this document with (or at least point to) "Open
Issues"
doc.
</General - very important>

>>>>I agree. Anyone want to take on this task???

It looks to me that we can have a version that is ready for QA on Monday. I
am not sure about the procedure prior to posting to QA. Does the TA group
need to vote on that Action (posting to QA) or not?

Regards,
Nikola