Ebbpss_comment disposition99k.pdf

Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
specification, our overall concern is the structure and readability of the document. improvements since the previous version, there still appears to be some duplication and redundancy of material. For example, Section 8.2 is highly redundant with much of section 6. • "Binary collaboration" in lines 2202- • The definition of "Business Partner Role" at lines 2248-2251 repeats verbatim lines 1334-1337. • "Business Transaction" is defined at In part this may be a feature of the structure the team have taken with this document. Currently, the approach is: This places the same object in three sections and hence to need to duplicate explanations and definitions. Perhaps, these could be combined as: Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
etc… This may also avoid the “cut and paste” errors, for example the "an" instead of "and" mistake occurs in both 2279 and 1518. In addition, we note from the change log (“Issues list”), that there are some issues that appear to be unresolved. For example, there is some confusion about the use and value of REA models. The change log notes these as not adopted, yet does not explain why it would only be partial and why this would not be appropriate. More concerning is the fact that the Business Process Analysis team’s documents still rely heavily on REA models, despite this resolution. Headers Should the date be January 2001? No section numbers in table of contents. If Specification Schema meets requirement then why use the Metamodel? If not, why use BP modeling and BP specification, and clarify that specification against BPSS is ebXML software interpretable while model against UMM metamodel is syntax neutral and non-interpretable. • “Business Signal Definitions” should Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
Has a difficult sentence construction with some missing and extraneous words. It possibly needs an example or analogy to clarify the meaning. The relationship of the Specification Schema to the UMM and its Metamodel should produced from using the Specification schema different from those developed using UMM? If we have to say "where possible" then we may have a problem here – what kinds of constraints couldn't be represented in XML Is the intention to say these signals are “two” should be “more”. NB not confined to Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
Business Document Flows." line 536 "A Business Transaction consists of a Requesting Business Activity, a Responding Business Activity, and either one or two Document Flows between them." Maybe “single” is a better term than “atomic”. Examples of these types of activities would The comma after Schema should be a period. “Specifically The” should be ““Specifically, Figure 4 is useful but doesn't match its caption. The discussion describes things that don't Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
appear in the figure, like "specification rules" added relates to UMM in this section, not to BPSS There isn't any logical reason for requiring that what gets stored in the repository is XML. UML could just as easily be stored and a transformation into XML could be done only The word “semantics” is somewhat overloaded in ebXML, can we suggest you just say “UML State which standards P2D comes from (may 8601. Actually W3C Schema Part 2 Datatypes uses ISO 8601 for time related data types (e.g. duration). Since the W3C Schema version will use this we should state that the DTD version expects this, however, the DTD cannot validate the string, whereas W3C Schema can. Sounds odd to say that all business documents have unique structures when we know that they will be composed from reusable components, which means they will have substantial structural similarity. Suggest use the term “varying”. Section 6.4.2.1 is a little hard to wade through. It might help to take the example (including a Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
diagram) starting at line 718 and give it a separate section like "Example". process. ebXML can be incrementally adopted. BPSS if it is to refer to any BP description at all “must” should be “could” (see point above). It would also help to put a separate section heading here for the issue about legally text. Change word isSuccess to isPositiveResponse. Attribute will be optional and will be of type "expression". It is merely the responders assertion of what constitutes a positive response, it is not by itself a determinant of overall transaction success. Should be a non-normative note. It may also pay to reference the document “E-Commerce Is the intention to mean “legally” binding or the more practical “commercially” binding. legally binding but have added more qualifying text. See issue #29. It may be useful to bring sections 6.4.4.2 and 6.4.2.2 closer as they cover the same example Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
but are currently separated by intervening being a useful change.) In any event, it has not been done. Section 6.5 repeats a lot from 6.4.1.1 and elsewhere. It may be better to put this earlier and then the other somewhat disjointed sections 6.5 has been reworked to fit better with 6.6. ebXML specification? If so, they need to be described here. How do these relate to the “Catalog of Common Business Processes” and the “E-Commerce and Simple Negotiation the BPSS Added reference to negotiation pattern under 6.1.(5) Why have full-colon at the end of the section Paragraphs should start on the left margin. Is the "need proper definition" a note to the and whole section on asynchronous has been dropped What is meant by ebXML messages? Are these ebXML Message Service messages, messages containing ebXML content? Does it matter Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
Is this really what non-repudiation means? What about “no denying the sending of a Avoid putting content in the title. If this is also known as a “ProcessException”, say so in the text. "an in" should be "as in" "the receipt must be non-reputable" should be "the receipt must be non-repudiatable". We understand "reputable" to mean "to have a good reputation, to be respected". Is that what is meant? - "requesting commerce"? Could it be "requesting information" or other things. maybe it just wants to engage some entity in the complementary role, whatever that is. Table between 2679-2680 and 2697 and 2699 and Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
If these signal structures are to be ebXML standards then there needs to be a discussion about intent, both now and in the future. What happens if ebXML adopts XML Schema before RosettaNet does and these signals are re-implemented by ebXML, only to have RosettaNet do them differently? This is the wrong copyright statement. Should business transaction s/b capitalized (Business Specifically: . If no response . role based on the receipt of a business signal. What business signal? Sent or received by whom? . Regardless of which combination of . is chosen and/or Response Document Flow is chosen, they always . To what does "they" refer? specification? preferably, they will be named using an URI scheme, and even more so, as be named here. Will change type of attribute to be URI I am still quite uncomfortable with this scheme. It does not permit a degree of flexibility that allows for a combination of persistent and transient security mechanisms. For instance, use of a persistent digital signature over the Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
contents of the message (or on selected parts) to provide for authentication as well as integrity combined with a transient encryption "isSecureTransport" qualify the security characteristics of the Document Flow is IMHO, isConfidential, isAuthenticated and isTamperProof have the enumeration of "persistent", "transient" and "none" (default) such that valid combinations of security mechanisms might be applied. asynchronous delivery channel is employed (such as SMTP) should not preclude the use of delivery channel can often (as in the case of HTTP) receive only a single "response". We (TP team and TR&P team) have recently established mechanisms to account for synchronous delivery channels. A "request" message can indicate whether a synchronous response is required, and the CPP/CPA can specify what manner of response will be returned synchronously (e.g. on the same channel on which the request was delivered, such as the HTTP 200 response). The response can be specified as being "signalsOnly", "signalsAndResponse", "responseOnly", or "none". What this means is that either the response message contains one or more of the business signals, the busines signals AND the response message combined, just the response message or "does not apply". I will grant that this is still a bit too loose for my tastes, but because the business signals are Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
not treated as first-class messages in the BPSS, it becomes a little difficult to be more specific. In any event, the statement that "a partner role that initiates an asynchronous business transaction does not need to receive any business signals" is an inaccurate statement IMHO. It is also unclear from my perspective that there is any manner of constraint that even if this were true could be used to preclude the association of a "pattern" that involved business signals. it isn't clear to me why a requesting role sends respondant that the transaction has been revoked. For me, what isn't clear is what relation the "transaction" has to the overall "conversation" a term used in CPP/CPA. It would seem to me that this might make for a new BusinessDocument as part of a new BusinessTransaction, but optionally contained within the same BinaryCollaboration with a transition and guard that reflects the failure. having the element/attribute descriptions alphabetized is actually quite difficult to follow. It would be preferable (IMHO) to have the descriptions follow the DTD "flow" from root element down through the descendant tree Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
with backward references when necessary. I had asked that an optional version attribute be added to Attachment and DocumentType such that this metadata might be included in the Manifest to provide an external means that a receiving party might use to determine whether it was capable of processing the content. Please add a version attribute. pattern is defined as CDATA. It probably BinaryCollaboration element is missing the pattern attribute in the description (present in timeToPerform is defined as CDATA in the DTD, but in fact has constraints that it be typed as an xsd:duration which "represents a duration of time. The value space of duration is a six- designate the Gregorian year, month, day, hour, minute, and second components defined in § 5.5.3.2 of [ISO 8601], respectively." This should be noted at the very least. timeToAcknowledgeAcceptance attributes also Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
refers to "SchemaName/DocumentType" which is either a typo or something which isn't at all clearly described. I am assuming that it should instead be "Schema/DocumentType"? DocumentType is indicated as having as a parent Schema and Attachment. Attachment is not defined as having any child elements other than Documentation. It would seem to me that DocumentType should be declared as having as Previously, I had indicated that DocumentType should have a version attribute. I stand corrected, the Schema element should have an optional version attribute for the reason previously cited. Schema element is defined as having as a parent Package which appears to be incorrect based on the description of Package, but is consistent with the DTD. Which is correct? I and fix documentation relative to Package accordingly. the sample specification schema document is this section/table needs to be updated to reflect Specifically, timeDuration is now duration and recurringDuration has been eliminated and replaced with g* primitives. see latest version of the XMLSchema part 2 specification. definition in the Message Service specification. We should try to reconcile this with the AcceptanceAcknowledgment elements defined Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
in this section. At the very least, we should attempt to place some structure on the OriginalMessageDigest element. This will be necessary for interoperability. In addition, some consideration needs to be given to adding a timestamp to these elements as they may be sent in a message later than the actual recorded receipt or validation might suggest based solely on the timestamp of the message which carries these elements. please see the Message Service specification for our Error element. Some attempt at reconciling this element with that specified in the MessageService specification should be undertaken. defining the various codes used in the Exception element as #PCDATA does an injustice to interoperability. Specifically, at the very least some recommendation should be given as to use of URIs and preferably URNs for the various codes. At the very least, some scoping mechanism should be incorporated to at least provide an identification as to the "type" system which defines the codes used. See the Message Service specification. the Exception element does not conform to the element naming/capitalization conventions adopted by ebXML (upper camel case for elements) as some of the elements are named with lower camel case names. I have a little bit, no make that lots, of trouble with this approach. While it might appear on the surface to be a reasonable approach to naming and name resolution, in practice, it will (I believe) be fairly difficult to a) enforce and b) realize in software. Because use of an Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
arbitrary attribute called 'name' rather than the built-in ID/IDREF converntion is used, there (DOMImplementation) that a name is a) unique within some scope (document would be my preference rather than element scoping) b) a reference to a scoped name An additional concern is that this scheme might be confused with an xpath expression, which it clearly is not. However, in realizing a software component to resolve names under this scheme, use of an xpath engine might be employed, but it would be, IMHO, difficult to engineer because of the non-deterministic structure of any given "scoped name". An ID/IDREF-based approach would make it cleaner to implement a parser enforced validation of constraints and it would also make it clearer as to which 'name' attributes are intended to be identifiers and which are intended to be references to an identifier. In addition, it would make it trivial to resolve references because the parser would provide an index into the document tree based on ID. we should adopt a consistent representation for expressing dates/times that is consistent with XMLSchema. In addition, use of c14n'ed dateTime should be adopted whereever possible (e.g. represented as UTC) Thus, a dateTime is expressed as CCYY-MM-DDTHH:MM:SSZ. Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
While the ebBPSS doesn’t define Business Document structures, more detail should be Objects, which may be based on ebXML Core Components specifications, as shown in Figures 7 and 11. Processes, and Business Information Objects …” Schema is an additional view of the metamodel, provided to …” Need to clearly state what Specification Schema production rules are capable of doing. Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
Structured Documents which may be already existing Business Document specifications or ones composed from Business Information Objects, which may be based on Core Components. It also provides for Unstructured Documents supplied from some other source. Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
This is a critical sentence. We need to make Clarify that context is determined from the process analysis, starting with requirements.” The UML Specification Schema isn’t sufficient Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
information model. The XML Specification Schema should be the focus for CPP/CPA. Follow 6.4.1 section heading with a reference Change Document Type to Business Document and show more detail in relation to Business relationships to Business Information Objects and Core Components as extended by context, from the ebXML Specification for the Role of Context in the Re-usability of Core Components and Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
Change Document Type to Business Document and add descriptive text of added construction team on drafting text if comment is accepted. Follow 6.4.2 section heading with a reference Follow 6.4.3 section heading with a reference Follow 6.4.4 section heading with a reference Terminal State should be Completion State DTD does not have this element as it is abstract). ‘onInitiation’ belongs to Transition Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
all associated text. UMM is unclear about meaning of this attribute, we believe it is for concurrent instances of the SAME transaction and as such> different from fork. BPSS will reflect it as such and distinguish it from fork. It should be clarified in UMM as well. Change Document Type to Business Document and show more detail in relation to Business Business Document as in Figure 9-12 of UMM. Also use this to clearly show relationships to Business Information Objects and Core Components as extended by context, from the ebXML Specification for the Role of Context in the Re-usability of Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
Core Components and Business Processes (ebCNTXT) Similar to 488-498, the UML Specification Schema isn’t sufficient for specifying a rules are specified that governed the one-time generation of the DTD Specification Schema from the UML Specification Schema. The production rules are defined for concrete…” (instead of PO Acknowledgement) since it is RequestingBusinessActivity starting the whole transaction. But this prompts me to ask a stupid question, inspired by an EDI document centric suggestion I gave someone on EDI-L at http://www.mail-archive.com/[email protected]/msg03097.html -i.e., how do you "signal" that a RequestingBusinessActivity has occurred when Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
the RequestingBusinessActivity documentType was never received? For example, what if you want to send a PO Acknowledgement to a manually called-in order? Would that have to be modeled with a separate business transaction, or is it assumed that an Order Entry system could trigger the successful completion of the RequestingBusinessActivity within the Business Service Interface? ebXML Compliance, the model must conform to the semantics and structure of the UMM. Change line 238 from “recommended” to “required”. The BPSpec Schema incorrectly defines the Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
Meta Model defines a set of business process viewpoints” and any other locations that assert the UMM Meta Model is a methodology. The firm agreement I seek is that the BPSS must be a strict subset of the UMM Metamodel, so that BPSS-compliant XML runtime business process specifications may be derived from UML models that conform to the UMM Metamodel. In other words, we need one and only one metamodel. This is an issue of conceptual integrity so everything fits together smoothly. Integrity of transaction model, or, the ability to form legally binding contracts and enact legal The firm agreement I seek is that the BPSS must conform to the requirements for the interchange of UN/ECE and the ABA. If the BPSS conforms to the business transaction believe this issue should be resolved as well. But I want to raise it in particular because I believe it is the most important business transactions right, the rest is gravy. If not, the Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
Separate service levels for transactions and Support for ebXML business transactions will be a great leap forward for the state of electronic business practice, and will handle collaborations, especially the BPSS multi-party design, splits, joins, etc. will be not only more difficult for software developers but also for business analysts. I recommend designating separate service or compliance levels for each degree of difficulty, so that simple transaction processors can be developed quickly and inexpensively. It's not that far beyond what people do now with RosettaNet PIPs. In specschema 0.90 we had included RosettaNet RNIF 1.0 dtd's as the recommended dtd's for business signals. For specschema 1.0 we need to at the very least update these to the much simplified RNIF 2.0. A couple of questions before I do so: 1. Does UMM have a set of signal DTD's we should use instead. 2. RNIF 2.0. does not have an acceptanceAcknowledgement. Should I just clone the RNIF 2.0. receiptAcknowledgement? 3. Should we include the generic notification of failure? (This is not a signal, but a generic Business Document to notify another party Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
about a failure). 4. Does anyone in core components have suggestions how to use core components in any of these signals, they have tags like telephone number etc. in them. Attached are the two signals receiptAcknowledgement and exception, and the notificationOfFailure. Datatypes are not referred to from any of the BP documents. Schema and DTD data types, and representation terms are supposedly going There's no need to parrot what's already in Inspired by Jamie Clark’s suggestion to look for a solution that preserves the current UMM mapping but achieve a better mapping to EDOC and future RosettaNet thinking I am making the following suggestion, which has several additional benefits listed below. Consider this a set of formal comments to spec schema v0.99 when the public review period closes (I am in Africa and may not be able to connect again). 1. BinaryCoillaboration giving it two AuthorizingRoles and allowing definition and implementationof a standalone BusinessTransaction 2. Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
BinaryCoillaboration giving it two AuthorizingRoles and allowing definition and implementationof a standalone DocumentFlow, i.e. support for a single message, in addition to the transaction support 3. DocumentFlowActivities each using a DocumentFlow. This would in essence be a renaming of Requesting/RespondignBusinessActivity, and a relaxation that there must be only two of them. The specification should also be provided as an stronger data typing and other advantages that the documentation to be aligned with the DTD. Not done, but no DTD or schema changes are needed. Attachment has a DocumentType attribute, The attribute "specification" is IMPLIED in the DTD at 2136. At 2175, it is called "Spec" and is REQUIRED. The attribute "waitForAll" has a default value of "true" in the DTD at 2053 in the DTD at 2136. At 2641, waitForAll is omitted from the attribute list. At 2647, waitForAll is documented as having a default value of "false". Topic: Conformance of BPSS to the CEFACT Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
recommend (use of "SHOULD") that business processes be logically modelled. The same documents require (use of "SHALL") any such 2. The BPSS references to the UMM are of ambivalence of some drafters about the UMM. Commenters are understandably confused. The 3. The BPSS should clearly identify the UMM version (e.g., N90 v9.1) to which conformance is required. If the authoritative version is not finalized by its owner (CEFACT TMWG?), the BPSS should state what assumptions if any are made about the final adoption, with or without changes, of the particular version in question. Specific instances: General (and Line 314-328): Any general references to 'metamodels' should be corrected to indicate that there is only one metamodel, that is logical in nature, not bound to a schema. This includes any remaining references to the 'business process and information metamodel' (which probably misleads readers into thinking there is a separate artifact, and should be deleted), and to the 'ebXML metamodel' (which should be considered candidates for a specific reference to the UMM, along with the manner if any in which the UMM constrains the process being references). Line 492: It is not clear to what the phrase "set Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
of specification rules" refers. Line 499-501: It is not clear whether an XML expression of a transaction is logically constrained by the UMM, if not explicitly modeled in UML. Topic: Transaction integrity and cardinality of 1. The UMM constrains logical transactions either of a one-way transmission (as in a notification, where no response is required) or a two-way exchange (as in offer/acceptance, 2. This limitation accomplishes two things: a. It permits an optimal upgrade path for users of widely-deployed EC/EDI formats using document-centric exchanges of X12 or EDIFACT messages (functional equivalents of paper documents). UMM allows those legacy documents to be encapsulated in logical wrappers that bear standardized transition and transaction control attributes. b. The request-response paradigm forces transactions to be expressed in terms of bilateral exchanges. This permits simple logical resolution of the success or failure of each initiated transaction, in a manner highly isomorphic to a legal or auditing analysis of the contract. Nonconforming responses to a request are correctly evaluated as failures, requiring a new proposal ('counteroffer') and thereby avoiding recursive failure to resolve whether success has occurred. Requestors are permitted to specify the nature of responses, Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
and the degree of security (e.g., nonrepudiation and receipt acknowledgment), but then required to abide by the result if the responder accurately conforms. Specific instances: Line 369-370: Reference to "one or two" document flows should be retained. Line 983: Cardinality of requesting and responding activities should be retained. Topic: Transaction integrity and location of forces transactions to be expressed in terms of bilateral exchanges. This permits simple logical resolution of the success or failure of each initiated transaction, in a manner highly isomorphic to a legal or auditing analysis of the 2. Nonconforming responses to a request are correctly evaluated as failures, requiring a new proposal ('counteroffer'), and thereby avoiding recursive failure to resolve whether success has 3. Requestors are permitted to specify the nature of responses, and the degree of security (e.g., nonrepudiation and receipt acknowledgment), but then required to abide by the result if the responder accurately conforms. The first principle permits requestors to issue binding offers, with a reasonable degree of certainty that they can constrain the terms of any contract formed by acceptance. (The parallel legal rule is that "the Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
offeror is the master of the offer.") The second principle permits responders to rely on the enforceability of the formed contract, with a reasonably small risk that the requestor will repudiate by asserting a lack of agreement. (The parallel legal rules are that acceptance of a valid offer forms a contract, and the "mirror image" rule that makes any nonconforming acceptance a rejection and counteroffer.) 4. The logical conclusion that a bilateral transaction has succeeded should be independently deducible from the artifacts available to each side. (Giving one or the other the right to declare "success" or "failure" short of valid acceptance of a valid offer gives that party an unwarranted repudiation right.) 5. A responding party should not be entitled to require 'acceptance acknowledgement' confirmation from the requesting party of its responding signal. (Note that Figure 6 at line 570 correctly omits the relevant arrow.) There are no "business rules" against which to validate at that step: the responder knows whether he has sent a respond that conforms to the strictures specified by the requester. Specific instances: Line 571-579 Consider whether 'business signals" is the correct generic phrase for these acknowledgement attributes. If so, use them throughout. Line 578: Add to the sentence at 578, after "purpose": "s, relating to the processing and management of transaction document flows, prior to evaluation of their terms ". Line 580: Delete or refine the vague reference Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
to the EDIFACT model TPA; delete the footnotes. Line 585: In place of the last five words of the sentence, insert "confirmed by the recipient as received as legible, prior to the application of any business rules or evaluation of its terms". Line 586: Delete or refine the vague reference to the EDIFACT model TPA; delete the footnotes. Line 585: At the end of the paragraph, insert the sentence: "The property '[[insert correct attribute]]' allows partners to agree that a [requesting] message should be pre-qualified by the recipient, i.e., confirmed by the recipient as being a valid answer under the business rules previously agreed, prior to the evaluation of its terms". Line 1044: Confirm that the attribute 'inIntelligibleCheckRequired (line 584) does not conflict with the parameter 'timeToAcknowledgeReceipt' here. Line 1240-1283: The ControlException and ProcessException signals should be evaluated as a source of inappropriate repudiation risk. They should only be available for use when the business signals require it (as described, e.g., in lines 1602-1608). Otherwise, must every responder hold back its shipment, after receiving RecieptAcknowledgement (from the requesting offeror) of its valid acceptance, until a time period elapsed without any ProcessException? If this risk remains, it should be noted in the document. Line 1617: The parameter 'timeToAcknowledgeAcceptance' should not be available to a responding document (and thus Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
does not belong in this superclass). See general comment (5) above. Line 1624-1625: Consider a wellformedness rule requiring that any use of the 'timeToAcknowledgeAcceptance' parameter be accompanied by a URI or reference to the alleged business rules being invoked. (Otherwise, the asserter of business rules is free to apply what he likes, which may be equivalent to a unilateral right to repudiate.) Line 1671-1676: The "isSuccess" attribute on a Document Flow should not be available to deprecate the logical conclusion reachable from comparing the requesting and responding documents (or a time out event). Line 2357: [Additional occurrences of parameter definitions needing refinement.] Line 2363: [Additional occurrences of parameter definitions needing refinement.] Line 2385: [Additional occurrences of parameter definitions needing refinement.] 1. The word "pattern" is overburdened in the 2. Most frequently we use it to mean a logical set of business process components that is referenced (or invoked, so to speak) by a CPP. Such a 'pattern' may be simple (one atomic transaction, perhaps wrapped in a simple binary collaboration) or complex (a large concatenation of transactions among multiple parties, together with the conditional relationships between them). Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
3. The explanation needs a bit of work. Specific instances: Line 439: Replace "using" with "user". Line 439: Replace "very different" with "an infinite number of specific". Line 440: After "collaborations", insert the following: "These specific combinations (which may be simple or complex, ranging from a single transaction to long logically-related chains of multiparty transactions) are referred to as 'patterns'. Patterns that express a commonly useful process can be re-used by others. The suggested practice of logical modeling using UMM, and the opportunity to make such modelled processes generally available to others through repositories, promote their re-use." Line 444. Revise to describe the N90 patterns simply as helpful examples of how the business signals interoperate. Lines 1029-1057: The use of the word "pattern" here varies. Sometimes (1040-42) it means a particular permutation of acknowledgement-attribute/business-signal settings. (This is a confusing use and should be rewritten.) Sometimes (1054) it means a set of components consisting of transactions and perhaps collaborations. (This use is consistent with the general BP vocabulary.) Sometimes (1057) it refers to the specific illustrative UMM N90 patterns that demonstrate certain permutations of the acknowledgement-attribute settings. (Those patterns should be described simply as helpful examples of how the business signals interoperate.) Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
The phrases "nonrepudiation" and "legally binding" may be misunderstood by readers. The functionality provided by the relevant parameters is to create artifacts that provide a reasonable level of practical assurance of nonrepudiation, or binding nature -- not to deterministically reduce the risk in question to zero. Specific instances: Line 415: Delete "legally binding for" and insert "designated as legally binding between". Line 415: Insert after "two partners" the phrase ", or otherwise govern their collaborative activity." Line 415: Consider a "for example" cross-reference to the example/discussion of "binding" in the Patterns supporting document. Line 579: Consider a "for example" cross-reference to the example/discussion of "nonrepudiation" in the Patterns supporting document. Line 1609-1616: Rewrite to make it clear that what are produced by the referenced parameters are data artifacts, not abstract "audit controls." Line 1609-1616: Consider a "for example" cross-reference to the example/discussion of "nonrepudiation" in the Patterns supporting document. Line 2311, 2357, 2363: [Additional occurrences of parameter definitions needing Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
Several issues about how this will work in practice: * What is the relationship of a multi-party collaboration XML document to the ebXML runtime CPA? * Who gets a copy of the multi-party collaboration document? Only some central party, or all participants? * Since the multi-party collaboration will be composed of several binary collaborations, what if the details of one binary collaboration should not be exposed to other participants of the multi-party collaboration? Followup to the discussion of ebXML business In some ebXML document, either the BPSS or some supporting document or appendix, there should be a clear statement of how to use ebXML business collaborations with business documents from other sources, including other XML formats like OAG, and also non-XML formats like X12 and EDIFACT. Precondition and ResultsIn-PostCondition Issues List for Public Review of BP Specification Schema Version 0.99 Originator
Suggestion for
Resolution
originat
(Jim Clark to explore UMM alignment: UMM to rename Preconditions-Precondition PostConditions-PostCondition.) http://lists.ebxml.org/archives/ebxml-coord/200104/msg00000.html http://lists.ebxml.org/archives/ebxml-bp/200104/msg00013.html http://lists.ebxml.org/archives/ebxml-bp/200104/msg00015.html http://lists.ebxml.org/archives/ebxml-bp/200104/msg00017.html http://lists.ebxml.org/archives/ebxml-bp/200104/msg00018.html http://lists.ebxml.org/archives/ebxml-bp/200104/msg00025.html http://lists.ebxml.org/archives/ebxml-bp/200104/msg00026.html http://lists.ebxml.org/archives/ebxml-bp/200104/msg00027.html http://lists.ebxml.org/archives/ebxml-bp/200103/msg00068.html 10 http://lists.ebxml.org/archives/ebxml-bp/200104/msg00033.html 11 http://lists.ebxml.org/archives/ebxml-bp/200103/msg00161.html 12 http://lists.ebxml.org/archives/ebxml-bp/200104/msg00054.html 13 http://lists.ebxml.org/archives/ebxml-bp/200104/msg00064.html 14 http://lists.ebxml.org/archives/ebxml-bp/200104/msg00083.html 15 http://lists.ebxml.org/archives/ebxml-bp/200104/msg00096.html

Source: http://www.ebxml.org/specdrafts/ebbpss_comment_disposition99k.pdf