[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC