[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Final DTD, XSD and XML Examples (was RE: final agreement on BPSS 1.0model)
Just for the record, attached are the final DTD, XSD and XML Examples I
delivered to Karsten just moments ago. While documenting the DTDs I found a
copy/paste error in which I failed to undo a previous change, that was
reneged. I also discovered a coding error that prevented proper inclusions
of other BP instances. See the notes in the header. I am sending them
because they have changed since the last set I posted earlier today/last
night and I need closure (I'm weird that way :). The official package will
still come from Karsten this afternoon with the BP Spec document.
Best regards,
________________________________________________________________
Kurt Kanaskie
Lucent Technologies
kkanaskie@lucent.com
(610) 778-1069 Note the new number!
-----Original Message-----
From: Kanaskie, Kurt A (Kurt)
Sent: Friday, April 27, 2001 1:15 AM
To: 'Karsten Riemer'; ebxml-bp@lists.ebxml.org
Subject: RE: final agreement on BPSS 1.0 model
<< File: BPSS_XML_V1.00.zip >> All,
Attached are the V1.00 versions of the DTD, XSD and examples. Sorry for the
delay, travel logistics and bandwidth prevented me from getting these out
earlier, its been quite a ride!
<<BPSS_XML_V1.00.zip>>
________________________________________________________________
Kurt Kanaskie
Lucent Technologies
kkanaskie@lucent.com
(610) 778-1069 Note the new number!
-----Original Message-----
From: Karsten Riemer [mailto:Karsten.Riemer@east.sun.com]
Sent: Thursday, April 26, 2001 4:25 PM
To: ebxml-bp@lists.ebxml.org
Subject: final agreement on BPSS 1.0 model
<< File: Word.Document.8 >> Here are the BPSS decisions from today (4/26)
All of these are final for version 1.0 and will be reflected in a document
1.0B to be sent out tonight.
(resulting uml class diagram attached, only change from this morning is
DocumentFlow rename to DocumentEnvelope)
Jim Clark attended the meeting, and we came to a conclusion on the last
issue
remaining from yesterday:
7. Document Envelope (issue 120, #3)
Proposed Resolution: Rename DocumentFlow to DocumentEnvelope AND align
the
attributes and semantics to be identical UMM and BPS.
There was agreement to go ahead with this renaming, AND to move UMM
towards
alignment
Jim Clark to promote with TMWG the following semantic alignment:
Exactly 1 DocumentEnvelope from Requesting activity to Responding
Zero or N possible (but mutually exclusive) DocumentEnvelopes from
Responding
activity to Requesting.
DocumentEnvelope to have the following attributes:
isPositiveResponse, isConfidential, isTamperProof, isAuthenticated
(This mean you can specify more than one possible response
DocumentEnvelope
at designtime, but at runtime there is never more than one sent from
responder
to requestor)
DocumentEnvelope to have one and only one primary BusinessDocument,
and any number of Attachments. The way to show this on a
BusinessTransactio
activity diagram is to have multiple object flow symbols and annotate them
as
mutually exclusive)
We also discussed signal alignment.
Jon Yunker and Jamie Clark will draft a proposal for alignment.
If we can get that agreed by BP list by tomorrow night, it will be in 1.0,
otherwise BPSS v1.0 signal definitions will be unchanged from BPSS v0.99
The remaining issues stand as ratified yesterday:
(Jamie to supply some supporting text for guaranteed delivery, and
isPositiveResponse)
1. Transaction parameters (issues 131, 132, 119, 12)
Resolution: Retain UMM transaction constraint,
Resolution: move timeToAcknowledgeAcceptance to requesting activity
Resolution: retain isNonRepudiationOfReceipt where it is at
BusinessAction
level
Resolution: retain isIntelligibleCheckRequired where it is at
BusinessAction level
This all based on Jamie and Jim both agreeing that it makes sense to
allow
responder
to independently require a signed and/or intelligibleChecked receipt
acknowledgement,
as long as it does not change the requirement that the transaction ends
upon receipt
of response, not upon receipt of receiptAck.
Jim Clark will ask TMWG approval to amend UMM accordingly:
UMM move timeToAcknowledgeAcceptance to requesting activity
UMM move isNonRepudiationOfReceipt to BusinessAction
UMM move isIntelligibleCheckRequired to BusinessAction
2. Synchronous (issue 40, 58)
Resolution: Drop attribute isSynchronous and all associated text
Jim Clark will ask TMWG approval to amend UMM accordingly:
UMM removes text about synchronous at line 1009 and 1032/1034
(there are other references to synchronous in BSV, but that layer is
non
in scope for ebXML)
3. Concurrent (issue 111):
Resolution: Retain attribute isConcurrent and 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.
4. Security Parameters (issue 57)
Resolution: drop isSecureTransportRequired from business transaction
level
altogether
Resolution: Do NOT cahange boolean to Persistent/Transient/NO
Document that the bolean value TRUE requests 'persistent' security, FALSE
requests
no security
Jim Clark had some hesitation based on some historical issues. Unless Jim
gets
back to us by end of tomorrow's meeting, this decision stands, regardless
of what
UMM decides to do.
Related issue: we will retain the isGuaranteedDeliveryRequired as a
boolean
at Business Transaction Level, and document that it is just an instruction
to
CPA negotiators to pick a reliable channel.
5. Legal (issue 134, 29-31, 42) Jamie's recommendations
Resolution: Retain word isLegallyBinding, tighten text
Resolution: 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.
Jim Clark liked this isPositiveResponse concept and will pursue it
relative
to UMM
6. Xpath/ID (issue 76)
Resolution: Adopt Kurt's proposal 5
Need to work examples of how to reference by concatenated name and/or by
ID
We recommend but cannot require use of Global ID's.
Note: this will eliminate need for concatenated tags
(BinaryCollaboration+AuthorizedRole)
This is not a UMM related issue.
8: New renaming issues (from BPE work):
Resolution: Rename Requires->Precondition and ResultsIn->PostCondition
Jim Clark to explore UMM alignment:
UMM to rename Preconditions->Precondition PostConditions->PostCondition
9. Completion vs. Termination
Resolution: rename TerminalState to CompletionState
(this is a UML diagram only issue, DTD does not have this element as it
is
abstract)
There are no remaining identified issues.
<<BPSS_XML_V1_2001_04_27.zip>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC