RE: TA TEAM - PLEASE REVIEW THE DISPOSITION OF COMMENTS ON THE TASPECV1.0

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Title: TA TEAM - PLEASE BE READY TO REVIEW THE DISPOSITION OF COMMENTS ON THE TA SPEC V1.0

Brian, Duane,

 

    please find attached my comments on the Disposition.

Mainly my comments concern comments that I have already posted for the V1.0 document and that have not been applied. I thought that if there was not "dissensus", the comments to V1.0 would have been incorporated.

 

I think that most of comments I reiterate actually point to some important element and are not simply editorial. I will be happy to discuss them further.

 

Best regards

 

/stefano

-----Original Message-----
From: Brian Eisenberg [mailto:BrianE@DataChannel.com]
Sent: 02 February 2001 02:09
To: ebXML Architecture (E-mail)
Cc: Klaus-Dieter Naujok (E-mail 2); Duane Nickull (E-mail); Tim McGrath (E-mail); Nagwa (E-mail); Jon Bosak (E-mail)
Subject: RE: TA TEAM - PLEASE REVIEW THE DISPOSITION OF COMMENTS ON THE TA SPECV1.0
Importance: High

TA team -

 

As I mentioned in the email below, please review the disposition package for the TA spec v1.0. The current version is also available for your perusal, but please keep in mind that we are not reviewing the specification. We are reviewing the disposition of comments. All documents are available on the TA private page at:

 

http://www.ebxml.org/project_teams/technical_arch/private/

 

To reiterate:

 

THIS IS NOT A REVIEW OF THE SPECIFICATION, BUT RATHER A REVIEW OF THE DISPOSITION OF COMMENTS ON V1.0. THE TA SPEC. THE LATEST VERSION - 1.0.1 IS CONSIDERED FROZEN, AND WE ARE PROCEEDING WITH THE UNDERSTANDING THAT IF ANY TA TEAM MEMBERS HAVE ISSUES WITH THE DISPOSITION OF COMMENTS, PLEASE PROVIDE SUGGESTIONS ON HOW TO ADDRESS THEM IN THE SPEC. ONLY SHOW-STOPPING SUGGESTIONS WILL BE TAKEN INTO CONSIDERATION, WHICH MAY RESULT IN SUBSEQUENT CHANGES TO THE SPEC BEFORE WE RESUBMIT THE DOCUMENT TO THE QR TEAM.

 

At this point, please take time to review the disposition package, and submit your vote of "APPROVE" or "NOT APPROVE" to the TA list by the end of business on Monday, February 5th.

 

Please email me if you have any questions.

 

Best regards,

 

Brian <now_consuming_large_quantities_of_beer/>

. . . . . . . . . . . . . . . . . . . . . . . .

Brian Eisenberg | Standards & Technology Liaison

600 108th Avenue NE | Suite 900 | Bellevue WA  98004
      T 425.467.2641 |  F 425.637.1192 | briane@datachannel.com

w w w . d a t a c h a n n e l . c o m

-----Original Message-----
From: Brian Eisenberg [mailto:BrianE@DataChannel.com]
Sent: Wednesday, January 31, 2001 11:35 AM
To: ebxml-architecture@lists.ebxml.org
Subject: TA TEAM - PLEASE BE READY TO REVIEW THE DISPOSITION OF COMMENTS O N THE TA SPEC V1.0

Team -

Duane and I have been working around the clock for the past three days on disposing of all the public comments received on the TA spec v1.0. We will be circulating the updated spec, along with a detailed disposition package by the end of the day tomorrow (Thurs). We would like the TA team to review the disposition package from Thursday - Monday. We would like to propose a vote by email to approve the spec for re-submission to the QR team. Please review the package and submit your vote to the TA list.

PLEASE KEEP IN MIND THAT THIS IS NOT A REVIEW OF THE SPECIFICATION, BUT RATHER A REVIEW OF THE DISPOSITION OF COMMENTS ON V1.0. AFTER WE RELEASE THE UPDATED SPEC (WHICH WILL BE V1.0.1) TO THE TEAM, IT WILL BE CONSIDERED FROZEN, WITH THE UNDERSTANDING THAT IF ANY TA TEAM MEMBERS HAVE ISSUES WITH THE DISPOSITION OF COMMENTS, SUGGESTIONS ON HOW TO ADDRESS THEM IN THE SPEC WILL BE TAKEN INTO CONSIDERATION, WHICH MAY RESULT IN SUBSEQUENT CHANGES TO THE SPEC.

Please email me if you have any questions, and keep an eye on the TA list for the disposition package. I should have it out sometime tomorrow.

Regards,

Brian

Title:

Comments on the Technical Architecture Document and Disposition V 1.0.1

Stefano Pogliani, February 2 2001

In Red the comments on my previous comments that have not been accepted.

In Blue new comments on parts that have been added or significantly changed since last revision.

UID/GUI related comments

In one of your comments you mention that UID/GUID are "a central part of ebXML". I think that many things, if not all, are "central" in ebXML. For this concept you use (line 417) the term "REQUIRED" which is very seldomly used in the document. I personally do not agree and I do not think that the discussion in the listserv on this topic has clearly gained a consensus on the need of giving so much importance to this topic

• Line 416 thru 436 (yes, all 21 lines!!!)
  They should be removed. In the TA document I do not see any need to write a book on GUID/UUID. This is something that will be dealt with by the RegRep Specification. In this context it is not important at all, it does not add anything to the explanation and imposes a "technical implementation" in a context (the technical architecture) which is at a different level.
  If really something should be said, it should be "All items stored in the RegRep SHALL be uniquely identified."
  
  I still keep my original comment.
  
  
  

• Line 437 and 438.
  Remove the sentence "A UID reference is ...mechanism."
  It is irrelevant (see previous comment).
  
  
  

  I still keep my original comment.
  
  
  

• Line 717 and 718
  The sentence "The mechanism for interfacing..." until "... GUID for each component." should be removed.
  The TA document is not the place for implementation details such as UID/GUID.
  
  I read your comment. But I still think that this could be accomplished referring to the « The mechanism to interface CC SHALL be the one defined by the RegRep. » I keep my comment.
  
  
  

• Line 728 and 729
  The last part of the sentence, from "and therefore each.." to the end should be removed.
  The TA document is not the place for implementation details such as UID/GUID.
  
  I read your comment. But I still think that this is redundant. I keep my comment.

Automatic Negotiation Comments

The current discussion in the TP listserv has been originated by a new requirement that was not present before. Given the constrains in terms of time for the TP group, it is very likely that the results of suh discussion will be postponed after V1. So, it is important to adhere to what is the current situation which does not prescribe any automatic negotiation.

• Line 306
  Remove the last part of the sentence which says « ebXML compliant software interface ».
  This part implies that there is some automatic negotiation capability on the infrastructure. But this is not specified anywhere else. So it is misleading.
  
  I keep my comment.

• Line 460 and 461.
  The following part of the sentence "...system and a Business Service Interface" should be changed into "...system and a Trading Partner".
  The use of "Business Service Interface" implies some automatic negotiation capability in the ebXML infrastructure that is not defined anywhere else.
  
  I keep my comment.
  
  
  

• Line 469 (NEW COMMENT)
  What is the meaning of « self enabled into the ebXML infrastructure » ?
  If you imply that the ebXML-compliant software is able to perform Discovery and Retrieval, I reiterate my comment on the automatic negotiation which is not specified by ebXML in V1.
  
  
  

• Line 470 and 471.
  The sentence which reads as follows: "A Trading Partner who has implemented an ebXML Business Service Interface can now begin the process of discovery and retrieval (Figure 6 below)." implies automatic negotiation, which is not specified anywhere else. Please remove « who has implemented an ebXML Business Service Interface ».
  
  I keep my comment.
  
  
  

• Line 472 to 475.
  The whole sentence staring at "Requests for updates..." until "...by and ebXML Application" should be removed. The sentence implies that the Business Service Interface is able to automatically talk to the ebXML RegRep and that is able to take initiatives autonomously. This is not specified anywhere else and, thus, is misleading.
  What I think is to be said, is that the ebXML RegRep should support such functionalities (update, create etc), not the Business Service Interface nor the ebXML Application.
  
  I keep my comment.
  
  
  

• Figure 6.
  The two boxes labelled "ebXML Business Service Interface (Application)" should be labelled "Trading Partner" instead. Otherwise there is the assumption of automatic negotiation. See previous comment.
  
  I keep my comment.
  
  
  

Other Comments

• Line 196 and 197
  Remove the « object oriented » reference. « Component oriented » is enough for the scope of the architecture and XML doesn't prescribe object orientation.
  COBOL applications which will become ebXML-compliant do not care of Object Orientation!
  
  In your comment, you mention that the QR team provided help on drafting this section. The text did not actually change, though, nor there was any objection to this comment from other people.
  
  
  

• Line 272 to 274
  I think that this bullet should introduce the name of the CPA as the one which « implements » such arrangements herein described. This would make the further reading more easier by positioning the CPA piece in the context.
  
  You have modified the sentence from « mechanism for describing a mututally agreed » into « mechanism for describing the execution of a mutually agreed ». This does not take in account my comment which was oriented to introducing the concept of CPA and CPP at this point (the same way as in the bullets from 1 to 4 you introduce the names of BusinessProcess etc)
  
  
  

• Line 296 to 298
  It is not clear from this sentence « who and how » verifies the format and the scenarios. I think it should be made clar if it is announced.
  
  I think that the sentence implies that the Registry has some mechanism for controlling information. So in this sentence I do not understand which is the subject (« after receiveing... »: who is receiving? Who is sending? ), I do not understand which verification is done (verification based on what?) and I do not understand if the Registry sends something to Company A in a spontaneous way or as a response to some input from Company A.
  I think that this is not marginal in the scenario. I think that this may confuse readers instead than simply presenting a high level scenario.
  
  
  

• Line 308.
  Remove the last part of the sentence «which says « on who it wants to conduct business transactions with Company A ».
  This part is confusing. The first part is enough to understand the idea.
  
  You mentioned that you accepted this comment. Actually you changed the « on who » into « on how ». This does not change the rationale for the comment I made. I keep my comment.
  
  
  

• Line 311.
  The step in which Company A accepts the arrangement is missing. So I propose to add (before the last sentence of the paragraph) : « Company A accepts the business agreement. »
  
  Originally there was a longer sentence which I proposed to trim, not to remove. You said that you would have accepted this suggestion but actually you removed the whole sentence which makes it difficult to read now.
  
  
  

• Line 320 to 325. (NEW Comment)
  This paragraph is simply not well postitioned on respect to the previous one. In the previous (lines 316 to 318) implies that the BOV and FSV are described immediately after (« ...the following two views... »). Now, this new paragraph breaks this logic.
  I would suggest to move Lines 320 to 325 BEFORE the lines 316 to 318.
  
  
  

• Comments on Figure 4.

• "Applications" ("internal business application" and "shrink-wrapped application") are pre-existent, they do not get defined at the same time of the ebXML infrastructure. For this reason, the two "Build" arrows in the middle of the figure are out of scope. I would remove them
  
  The FSV may describe all of that, but the « Internal Business Application » and the « Shrink-wrapped application » are already there and do not need to be built. What needs to be built is the piece of software that makes these applications speaking « ebXML » (which is the Business Service Interface).
  The FSV may describe these things only for applications that need to be built from scratch. But this does not seem to be the case of your picture. In your picture it is the Business Service Interface that plays the role of granting the applications to speak « ebXML »...
  So, I keep my comment to remove the « build arrows » from that context and to move the arrows to point to the « Business Service Interface » boxes.
  
  
  

• On the other end, the "Business Service Interface"s need to be built when implementing the ebXML infrastructure. "Build" arrows should point to them
  
  See previous comment.
  
  
  

• "Register CPP" blocks and "Retrieval of Profiles..." arrows. It seems that the CPPs are sent/received automatically by the applications. This implies automatic negotiation which is not specified anywhere else. In effect these arrows should not go to the "applications" but to another box representing "Company A" (an "Company B").
  It is important to distinguish what a "Company X" does (which implies human activity to screen the information) from what the legacy does (which implies the execution of software to properly realize the CPA).
  
  See my previous comment on this same topic. Automatic Negotiation is not in the scope of V1. The negotiation so far is not defined and, thus, I suggest that in the picture it is performed by generic « Company A » and « Company B » boxes.
  
  
  

• So, I would add the two "Company A" and "Company B" boxes, I would re-direct some arrows as explained before and I would use different line-patterns to distinguish "messaging transfer" which is exploited automatically by the ebXML infrastructure from "human browsing and storing".
  
  The justification you give here does not contribute to the matter and does not help me in understanding your point and the reasons why you did not accept the comment.
  
  
  

• The picture does seem too much explained. A lot of focus in the explanation is given to the RegRep, but the picture is dealing with the "Functional Service View" which is more complex and wide than the single RegRep. Some explanation is definitely required here.
  
  The justification you give here does not contribute to the matter and does not help me in understanding your point and the reasons why you did not accept the comment.
  
  
  

• Line 453.
  "...a copy of the ebXML Framework specification".
  My original comment was saying « Specification of what? I think that a Trading Partner may require the "Business Process" definitions of the BPs referenced by some other partner's CPP... Saying "specification" is too generic here. »
  
  Now, you have changed « ebXML specification » into « ebXML Framework Specification ». My question remains the same. Which are these specifications? Where are they written ?
  
  
  

• Picture 5.
  Change the box "ebXML Business Service Interface (Application)" with a box labelled "Trading Partner" (see previous comment).
  
  Sorry but in the latest version I have of the glossary (0.93), the BSI is not defined. Maybe there is a new version that I did not see. I keep my comment.
  
  
  

• Line 494 to 495.
  The sentence "If it becomes necessary..." until "...Discovery and Retrieval Phase." should be removed.
  There is no need to use the RegRep at runtime or, at least, it has never been specified anywhere else. This is misleading.
  
  Which situations are thinking of? I cannot imagine that the RegRep is used at runtime, but I will be happy to see examples of the contrary. Otherwise, I keep my comment.
  
  
  

• Paragraph between line 510 and 512.
  Whilst the previous paragraph (502-505) deals with the CPP, this one should deal with the CPA. Actually, a part from the difference in the acronym (CPA instead than CPP) this paragraph looks too much like the previous one and seems a repetition. It would be necessary to exploit the specificity of the CPA here.
  
  If you read the relevant lines (510 to 512) and compare with 502-505, you may see what I mean. They look exactly the same and a reader would think that there was a cut-paste issue and skips reading. It looks like the « Collaboration » and the CPP are the same thing...
  
  
  

• Line 518
  The reference to the "Service Interface" is not clear. What is really meant by "service interface" in the context of this sentence?
  
  You mentioned that you corrected this but actually it was not.
  
  
  

• Line 519 versus line 524 (NEW COMMENT)
  There is a contraddiction. The Party « MAY » or « SHOULD » register in regrep ?
  
  
  

• Line 580 (NEW COMMENT)
  The last part of the sentence « ...who will use that interface for a given Business Process » should be changed into « ...who will execute such agreement. »
  
  
  

• Line 603 to 605 (NEW COMMENT)
  This looks like a requirement, not an architectural description. I would remove it.
  
  
  

• Lines 671, 675, 679.
  All the "SHALL" should be changed into "is". This is NOT a requirement document, it is the explanation of the Technical Architecture. The TA is based on things that have been already specified.
  
  Which are the reasons for not having changed this? The reason is not explained in your comments
  
  
  

• Line 822 thru 922 (all the Registry part).
  No mention is made here on the "Repository Information Model" which is an important and distinctive part of the RegRep. A couple of words, a little paragraph on this ?
  
  I read your comment, but I was not able to find it in the text. I keep my comment.