OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: comments on v0.99 of BP Specification Schema doc

BP PT colleagues,

Following are Chris Ferris' comments on the v0.99 BP Specification Schema.


Paul Levine
BP PT Co-lead

                    ferris                   To:     plevine@telcordia.com, Karsten Riemer - Sun IR Development 
                    <chris.ferris@eas        <kriemer@volcano.East.Sun.COM>                                     
                    t.sun.com>               cc:     Christopher Ferris <chris.ferris@east.sun.com>, (bcc: Paul 
                                             R. Levine/Telcordia)                                               
                    04/04/01 11:01 PM        Subject:     comments on v0.99 of BP Specification Schema doc      


Please forward to the BP alias, as I am not subscribed.

The following are my comments on the v0.99 BP Specification Schema
document recently released for public review.



section 6.5 Core Business Transaction Semantics

line 996 - business transaction s/b capitalized (Business Transaction)

line 1004 - same comment

lines 1012-1018 - this description makes no sense at all.
          ... If no response ... role based on the receipt of a business
     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?

lines 1054-1056 - why not assign them names with this specification?
     preferably, they will be named using an URI scheme, and even
     more so, as URNs

lines 1081-1100 - 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 contents of the message
     (or on selected parts) to provide for authentication as well as
     integrity combined with a transient encryption of the message on
     the wire. Having "isSecureTransport" qualify the security
     of the Document Flow is IMHO, a poor design. I would much prefer that
     isConfidential, isAuthenticated and isTamperProof have the enumeration
     of "persistent", "transient" and "none" (default) such that valid
     combinations of security mechanisms might be applied.

lines 1108-1121 - now I am VERY confused! Just because an asynchronous
     delivery channel is employed (such as SMTP) should not preclude
     the use of business signals. OTOH, a synchronous 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 not treated as first-class
     messages in the BPSS, it becomes a little difficult to be more

     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.

line 1257 - ... deal with the ...

line 1257 - run-on sentence, big time

line 1277-1283 - it isn't clear to me why a requesting role sends a
     *separate transaction* notifying the 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 difficult implementation.

general section 8.2 - having the element/attribute descriptions
     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 with backward
     references when necessary.

line 2168 - 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.

line 2006 - pattern is defined as CDATA. It probably should be constrained
     to be typed as an xsd:uriReference.

line 2202 - BinaryCollaboration element is missing the pattern attribute
     in the description (present in the DTD)

line 2011 & 2216 - timeToPerform is defined as CDATA in the DTD, but in
     has constraints that it be typed as an xsd:duration which
     "represents a duration of time. The value space of duration is
     a six-dimensional space where the coordinates designate the Gregorian
     year, month, day, hour, minute, and second components defined
     in of [ISO 8601], respectively." This should be noted
     at the very least.

line 2066 & 2300 - see previous comment regarding timeToPerform

line 2096, 2097, 2107, 2108, 2529, 2530, 2553, 2554 - both
     and timeToAcknowledgeAcceptance attributes also should be constrained
     to be of type xsd:duration. See previous comment on timeToPerform.

line 2399 - 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"?

line 2401 - DocumentType is indicated as having as a parent Schema and
     Attachment is not defined as having any child elements other than
     Documentation. It would seem to me that DocumentType should be
     as having as parents Schema and DocumentFlow.

line 2569 - Previously, I had indicated that DocumentType should have a
     attribute. I stand corrected, the Schema element should have an
     version attribute for the reason previously cited.

line 2583 & 2480-2499 - 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 am assuming that the
     DTD is correct.

line 2745 - the sample specification schema document is inconsistent with

line 3005 - this section/table needs to be updated to reflect the PR
     specification. Specifically, timeDuration is now duration and
     has been eliminated and replaced with g* primitives.
     see latest version of the XMLSchema part 2 specification.

section 9.2 - Business Signal Structures

- please see the Acknowledgment element definition in the Message Service
     specification. We should try to reconcile this with the
     and AcceptanceAcknowledgment elements defined in this section. At the
     very least, we should attempt to place some structure on the
     element. This will be necessary for interoperability. In addition,
     consideration needs to be given to adding a timestamp to these
     as they may be sent in a message later than the actual recorded
     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
     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

- the Exception element does not conform to the element
     conventions adopted by ebXML (upper camel case for elements) as some
     the elements are named with lower camel case names.

line 2695 - I have a little bit, no make that lots, of trouble with this
     While it might appear on the surface to be a reasonable approach to
     and name resolution, in practice, it will (I believe) be fairly
difficult to
          a) enforce and
          b) realize in software.
     Because use of an arbitrary attribute called 'name' rather than the
     ID/IDREF converntion is used, there can be no enforcement by a
     XML parser or document builder (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
     In addition, it would make it trivial to resolve references because
     parser would provide an index into the document tree based on ID.

line 3174-3176 - we should adopt a consistent representation for expressing
     dates/times that is consistent with XMLSchema. In addition, use of
     dateTime should be adopted whereever possible (e.g. represented as
     Thus, a dateTime is expressed as CCYY-MM-DDTHH:MM:SSZ.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC