[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: Vienna POC demo - BP portion
All, Another note from Karsten affecting participants with dynamic access to CPPs and/or CPAs. -Philippe _______________________________ Philippe De Smedt Architect Viquity Corporation (www.viquity.com) 1161 N. Fair Oaks Avenue Sunnyvale, CA 94089-2102 (408) 548-9722 (408) 747-5586 (fax) pdesmedt@viquity.com -----Original Message----- From: Karsten Riemer [mailto:Karsten.Riemer@east.sun.com] Sent: Thursday, May 03, 2001 2:43 PM To: Karsten Riemer Cc: colm@bindsys.com; LONJON Antoine; 'William Cox'; Brian Hayes; Cory Casanave; Nita Sharma; Karsten Riemer; Sid Askary; Sigmund Handelman; Philippe DeSmedt; Eckenfels. Bernd Subject: RE: Vienna POC demo - BP portion Here is Kurt's summary of DTD changes .99 to 1.0. I attach the whole file which also has the chronological change log, but here is the section by element (With my comments interspersed): The following describe the changes per element/attribute ========== Element content changes: ========== <!-- This group of changes are not likely to cause much grief, they are about packaging and documentation--> <!ELEMENT ProcessSpecification (Documentation*, (Include* | DocumentSpecification* | ProcessSpecification* | Package | BinaryCollaboration | BusinessTransaction | MultiPartyCollaboration)*)> <!ELEMENT Include (Documentation*)> <!ELEMENT Package (Documentation*, (Package | BinaryCollaboration | BusinessTransaction | MultiPartyCollaboration)*)> <!ELEMENT Start (Documentation*)> <!ELEMENT Success (Documentation*)> <!ELEMENT Failure (Documentation*)> <!ELEMENT Fork (Documentation*)> <!ELEMENT Join (Documentation*)> ========== Element name changes: ========== <!-- This group of changes were made for UMM alignment and in response to issues--> DocumentFlow --> DocumentEnvelope DocumentType --> BusinessDocument EbXmlProcessSpecification --> ProcessSpecification Schema --> DocumentSpecification ========== Element content changes for attributes: ========== <!-- This group of changes were made for UMM alignment and in response to issues--> Attachment@version --> added BusinessTransaction@isSecureTransportRequired --> removed BusinessTransactionActivity@isSynchronous --> removed DocumentSpecification@version --> added ProcessSpecification@name --> type ID RespondingBusinessActivity@timeToAcknowledgeAcceptance --> removed ========== Attribute name changes: ========== <!-- This group of changes were made for UMM alignment and in response to issues--> requires --> preCondition resultsIn --> postCondition documentType --> businessDocument isSuccess --> isPositiveResponse ========== Attribute default value changes: ========== <!-- This group of changes were made for UMM alignment and in response to issues--> isConcurrent false --> true RequestingBusinessActivity@name --> optional RespondingBusinessActivity@name --> optional ========== ID/IDREF changes: ========== <!-- This group of changes were made for alignment with ebXML preference for ID/IDREF--> See comment section above for Issue #76. Basically optional nameID attributes of type XML ID were added to all elements that had a name attribute. referenceNameIDRef attributes of type XML IDREF added to all elements that had referenceName attributes (e.g. authorizedRole and authorizedRoleIDRef). I hope we can all agree to use 1.0. My suspicion is that this only affects the demo'ers of BP modeling tools, i.e. Bind, Iona/Netfish, Fujitsu. DataAccess is already using 1.0. I don't think any of the message exchanging demo'ers are relying on the BPSS, but I cannot get a hold of anyone at POC to confirm/deny that. -karsten PS for completeness I also attach the W3C schema version of the DTD sent out earlier. >I strongly recommend that we use BPSS version 1.0. >That is currently posted as an appendix to the BPSS spec at ebxml.org. >I attach it here, as well. >I just talked to Kurt Kanaskie and he will send me a summary of the changes >.99 to 1.0 changes which I will forward to this distribution. > >thanks, >-karsten > > >> >>Antoine, >> >>I made some changes to your Retail.xml file so that it would obey the ebXML >>BPSS 0.99 DTD. The new file is attached. Can someone pls confirm that the >>POC demo will be using 0.99 of the BPSS ? >> >>Look forward to meeting you all in Vienna. >> >>regards, >> >>Colm. >> >>-----Original Message----- >>From: LONJON Antoine [mailto:alonjon@mega.com] >>Sent: Tuesday, May 01, 2001 8:54 PM >>To: 'William Cox'; Colm Caffrey; Brian Hayes; Cory Casanave; Nita >>Sharma; LONJON Antoine; Karsten Riemer; Sid Askary; Sigmund Handelman; >>Philippe DeSmedt >>Cc: Eckenfels. Bernd >>Subject: RE: Vienna POC demo - BP portion >> >> >>William, >> >>Here is the second version proposed for the POC in Vienna. >>I have a first approach to reconcile the POC scenario and the worksheets >>from the business process analysis group. >> >>The POC scenario is presented in two ways. A end to end point of view and a >>collaboration point of view where the transaction definition layer is >added. >>The models coming from the for the retail sample worksheets are presented >>closely to UMM. >>I need to add the payload definition. >> >>The retail.xml file is the generated ebXML Collaboration file. >> >>I am also working on a first version of the HL7 scenario. I have reversed >>the DTD in UML. >> >> >> >> >> >>-----Original Message----- >>From: William Cox [mailto:William.Cox@bea.com] >>Sent: Monday, April 30, 2001 10:25 AM >>To: Colm Caffrey; Brian Hayes; Cory Casanave; Nita Sharma; LONJON >>Antoine; Karsten Riemer; Sid Askary; Sigmund Handelman; Philippe >>DeSmedt; William Cox >>Cc: Eckenfels. Bernd >>Subject: Re: Vienna POC demo - BP portion >> >> >>I don't know whether this got out; several people responded, but I'd like >to >>hear from Netfish, CommerceOne, and Sun on the BP group presentation/POC, >as >>well as fitting in with models of the POC interactions for the two demos >>planned for Vienna. >> >>Please acknowledge, even if you're not interested in participating. >> >>I'm planning on being on the BP call today, Monday 4/30. >> >>Thanks! >> >>bill >> >>BP coordination for Vienna POC >>-- >>William Cox >>BEA Systems Architecture and Standards >>140 Allen Road Liberty Corner NJ 07938 >>+1 908 580 3458 fax +1 908 580 3060 >>William.Cox@bea.com >> >> >>William Cox wrote: >> >>> All - - >>> >>> I'm sending this email to all of you about planning for the ebXML Proof >>> of Concept demo in Vienna next month. We hope that several of you can >>> show ebXML BP and/or CC technologies, in addition to a group >>> presentation by the BP team. >>> >>> There is a face-to-face meeting in Maryland next week, as well as >>> Monday/Tuesday of the ebXML meeting. I'm hoping that your BP-related >>> efforts can be independently done, so fine tuning early in the meeting >>> week will be all that's necessary. >>> >>> The just-revised detailed planning document will be sent out tomorrow >>> morning (U.S. Eastern Daylight Time), but the BP-related portions are >>> not in place. We will also send this document directly to you, as you >>> may not be closely monitoring the ebxml-poc list. >>> >>> There are two scenarios we will show: >>> eBusiness with payment authority and a variety of payloads >>> HL7/Healthcare scenario with HL7 payloads, hospital, lab, etc >>> There are interaction diagrams in the planning document, along with >>> drawings and descriptions. These are available as Rose models if that >>> might be useful to you (Sig?). We needed to nail down our scenarios, >>> which took longer than we had hoped. >>> >>> To summarize what I'd like to see in the demo: >>> >>> (1) At the start of the POC time, the Business Process Team will discuss >>> BP modeling and definition issues to set the scene (10 minutes or so) >>> >>> (2) For eBusiness: >>> One participant shows a model (possibly tied into CPP/CPA >>> formation) >>> Another participant shows a model (preferably of a different >>> portion) >>> (one could show building a model, another modifying it to fit the >>> demo) >>> This will be woven around the demonstration. >>> >>> (3) For HL7 >>> One or two participants as above. >>> >>> We hope that you will be able to participate. Sid Askary is the one to >>> contact about ground rules and how to present; I'm the one to talk to >>> about details of the planning and the content. >>> >>> bill >> >
This document describes the DTD changes from version 099 to 1.0 in two different formats, chronological and via the element names. Kurt Kanaskie, 2001-05_03 The following comments describe the changes as they occured chronologically: <!-- Kanaskie, Changes as of 2001-04-23: - As per Karsten's POC Sample - Added binaryCollaboration attribute to Performs which is used to qualify the AuthorizedRole - As per Karsten's POC Sample - Added fromBinaryCollaboration and toBinaryCollaboration attribute to Transition which is used to qualify the BusinessState - Issue #57 Resolution - Chris Ferris suggestion: - Changed isAuthenticated, isConfidential, isTamperProof from boolean to, SecureTransport, enumerated values of (no | persistent | transient) "no" - Model change DocSecurity abstract class attributes become type SecureTransport - Removed isSecureTransportRequired from BusinessTransaction - Added to BusinessTransaction triplet of new isAuthenticated, isConfidential, isTamperProof. - Model change BusinessTransaction inherits from DocSecurity - Issue #63, #71 resolution - Added version attribute to DocumentSpecification - Issue #63, #71 resolution - Added version attribute to Attachment - Issue #102 resolution - Changed DocumentType to BusinessDocument - Issue #102 resolution - Changed documentType to businessDocument to keep references consistent. - Issue #? resolution - Changed Schema to DocumentSpecification - Issue #? resolution - Moved DocumentSpecification out of Package to EBXMLProcessSpecification - Model change DocumentSpecification is child of PackageContainer abstract class - Issue #111 Resolution - Removed isConcurrent from BusinessTrascationActivity - Issue 40, 58 Resolution - Removed isSynchronous from BusinessTrascationActivity - Issues 131, 132, 119, 12 Resolution - Remove isNonrepudiationOfReceiptRequired attribute from RespondingBusinessActivity - Model change - Moved attribute "isNonrepudiationOfReceiptRequired" from BusinessAction to RequestingBusinessActivity - Issues 131, 132, 119, 12 Resolution - Remove timeToAcknowledgeAcceptance attribute from - Issue #? Resolution - Moved attribute "timeToAcknowledgeAcceptance" RespondingBusinessActivity - Model change - Moved attribute "timeToAcknowledgeAcceptance" from BusinessAction to RequestingBusinessActivity - Editorial - Changed EbXml to EBXML, I think this is correct use of UpperCamelCase --> <!-- Kanaskie, Changes as of 2001-04-25: - Undid - As per Karsten's POC Sample - Added binaryCollaboration attribute to Performs which is used to qualify the AuthorizedRole, due to Naming/XPath/ID resolution, regardless of the solution a reference to an AuthorizedRole will be fully qualified. - Undid - As per Karsten's POC Sample - Added fromBinaryCollaboration and toBinaryCollaboration attribute to Transition which is used to qualify the BusinessState due to Naming/XPath/ID resolution, regardless of the solution a reference to an AuthorizedRole will be fully qualified. - Question? - Why does CollaborationActivity contain a binaryCollaboration reference? Is it to require that a CollaborationActivity only use AuthorizedRoles from the same BinaryCollaboration? - Editorial - Changed Include, Start, Success, Failure, Fork and Join from EMPTY to (Documentation*) - Issue #76 Resolution - Provide human readable names and references, as well as ID and IDREF identifiers and references. - Added optional nameID attribute of type XML ID to each named element (DocumentSpecification, BusinessDocument, Package, BinaryCollaboration, MultiPartyCollaboration, AuthorizedRole, Fork, Join, BusinessTransactionActivity, CollaborationActivity, BusinessTransaction, RequestingBusinessActivity, RespondingBusinessActivity, Attachment, BusinessPartnerRole) - Added optional elementNameIDRef attribute of type XML IDREF to each element that contains references to other elements (fromBusinessStateIDRef, toBusinessStateIDRef, businessTransactionIDRef, fromAuthorizedRoleIDRef, toAuthorizedRoleIDRef, binaryCollaborationIDRef, businessDocumentIDRef, authorizedRoleIDRef) - Issue #111 re-Resolution - Re-added isConcurrent to BusinessTranscationActivity - Issue #57 re-Resolution - - Removed (previous resolution change) triplet of new isAuthenticated, isConfidential, isTamperProof from BusinessTransaction - Model change none (undo previous resolution changes) - Changed isAuthenticated, isConfidential, isTamperProof back to boolean. - Model change remove SecureTransport enumeration since no longer used. - Editorial - Changed EBXMLProcessSpecification to ProcessSpecification to align with CPP - Issue ? - Changed isSuccess to isPositiveResponse, made optional - Issue ? - changed requires to preCondition and resultsIn to postCondition in both BinaryCollaboration and BusinessTransaction --> <!-- Kanaskie, Changes as of 2001-04-25: - Issue #113 Resolution - Changed DocumentFlow to DocumentEnvelope --> <!-- Kanaskie, Changes as of 2001-04-27: - Bug Fix - Changed ProcessSpecification to be correct as per the first model diagram. - Bug Fix - Changed name in ProcessSpecification to be an ID type to satisfy the CPP requirement. --> <!-- Riemer, Changes as of 2001-28-03: - Bug Fix - Changed RequestingBusinessActivity and RespondingBusinessActivity name attributes to optional --> The following describe the changes per element/attribute ========== Element content changes: ========== <!ELEMENT ProcessSpecification (Documentation*, (Include* | DocumentSpecification* | ProcessSpecification* | Package | BinaryCollaboration | BusinessTransaction | MultiPartyCollaboration)*)> <!ELEMENT Include (Documentation*)> <!ELEMENT Package (Documentation*, (Package | BinaryCollaboration | BusinessTransaction | MultiPartyCollaboration)*)> <!ELEMENT Start (Documentation*)> <!ELEMENT Success (Documentation*)> <!ELEMENT Failure (Documentation*)> <!ELEMENT Fork (Documentation*)> <!ELEMENT Join (Documentation*)> ========== Element name changes: ========== DocumentFlow --> DocumentEnvelope DocumentType --> BusinessDocument EbXmlProcessSpecification --> ProcessSpecification Schema --> DocumentSpecification ========== Element content changes for attributes: ========== Attachment@version --> added BusinessTransaction@isSecureTransportRequired --> removed BusinessTransactionActivity@isSynchronous --> removed DocumentSpecification@version --> added ProcessSpecification@name --> type ID RespondingBusinessActivity@timeToAcknowledgeAcceptance --> removed ========== Attribute name changes: ========== requires --> preCondition resultsIn --> postCondition documentType --> businessDocument isSuccess --> isPositiveResponse ========== Attribute default value changes: ========== isConcurrent false --> true RequestingBusinessActivity@name --> optional RespondingBusinessActivity@name --> optional ========== ID/IDREF changes: ========== See comment section above for Issue #76. Basically optional nameID attributes of type XML ID were added to all elements that had a name attribute. referenceNameIDRef attributes of type XML IDREF added to all elements that had referenceName attributes (e.g. authorizedRole and authorizedRoleIDRef).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC