[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.
Regards,
Paul Levine
BP PT Co-lead
christopher
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
Paul/Karsten,
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.
Cheers,
Chris
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.
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?
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
characteristics
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
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.
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
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 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
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-dimensional space where the coordinates 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.
line 2066 & 2300 - see previous comment regarding timeToPerform
line 2096, 2097, 2107, 2108, 2529, 2530, 2553, 2554 - both
timeToAcknowledgeReceipt
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.
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 parents Schema and DocumentFlow.
line 2569 - 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.
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
the
DTD
line 3005 - this section/table needs to be updated to reflect the PR
XMLSchema
specification. Specifically, timeDuration is now duration and
recurringDuration
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
ReceiptAcknowledgment
and AcceptanceAcknowledgment elements defined 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.
line 2695 - 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 arbitrary attribute called 'name' rather than the
built-in
ID/IDREF converntion is used, there can be no enforcement by a
standard
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
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.
line 3174-3176 - 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC