[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-cppa] Comments on action & ActionContext
I also think revisiting ActionContext,
especially if the 2.1 maintenance version waits on BPSS 2.0 committee draft
approval, would be a good idea. I would like Hima to comment on your
remarks, as he is the ActionContext expert, but I know he is quite busy
currently. Here are some initial reactions and
questions concerning your comments:
From: Steve Capell
[mailto:steve.capell@redwahoo.com] Dale, One of the things that I thought was
confusing / wrong in the 2.0 spec was the mapping of action and action context
in the <ThisPartyActionBinding> element. These elements /
attributes are supposed to map to elements in a bpss schema - which, in turn,
carries the semantics of the UMM model from which schema have been
generated. That being the case, these values should map to fields
of type ID (in the referenced BPSS) so that there can be no ambiguity. If
you look at the bpss specification (v1.1 and draft 2.0), each element
binaryCollaboration / Transaction / activity / etc element carries both name
and nameID attributes. Name is just an xsd string whilst nameId is of
type ID (ie must be unique in the namespace of the bpss instance). So the CPA action and ActionContext
elements and attributes really should of type QName and should map to the
nameID elements in the corresponding bpss. The example instance on page
26 has values for these key reference fields that are clearly just meaningless
strings (from a machine readability perspective):
tp:binaryCollaboration="Request Purchase Order"
tp:businessTransactionActivity="Request Purchase Order"
tp:requestOrResponseAction="Purchase Order Request Action"/> I'd suggest that the cpa
should have a namespace declaration at the top that defines the namespace of
the bpss instance (eg xmlns:bp=rosettanet-org:processes.3A4.bpss) and then the
action attribute and each actionContext attribute should be a QName that links
to the corresponding nameId field in the bpss instance. Something like: BPSS INSTANCE ******************** <ProcessSpecification targetNamespace=rosettanet-org:processes.pip3A4
xmlns:tns=rosettanet-org:processes.pip3A4 ...... <BinaryCollaboration
name="Request Purchase Order"
nameId="order.request" CPA INSTANCE ******************* <tp:CollaborationProtocolAgreement
xmlns:bp=rosettanet-org:processes.pip3A4 .... <tp:ActionContext
tp:binaryCollaboration="bp:order.request"
etc... Without this level of
precision, the architecure begins to crumble.... Regards, Steve Capell Red Wahoo Pty Ltd +61 410 437854 From: Hi, Nov 12 we can begin to discuss aspects of the 2.1
maintenance release. The main missing elements are the SOAP header and module
descriptions. The WSDL extensions need some final changes. BPSS and Messaging 3.0 may give us some reasons to modify
Action, Service, Role and Action Context. In the hope of letting you look over these sections I am
posting an editor’s draft. This draft should include all the errata we have noted so
far. The examples for alternative messaging, wsdl, and soap
support are preliminary. I will be traveling next week so I won’t have time to
edit too much until Nov 9. If you notice something let me know and I will start
an issues list on the draft. Thanks, PS The appendices are getting numbered consecutively with
the main sections. I will find out how to change this eventually, but there
will be appendices similar to the 2.0 version. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]