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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[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:

 

  1. While both W3C schema and wsdl specifications or drafts make extensive use of qnames in their referential apparatus, the W3C TAG warns that qnmes in content (for example, used in a referring expression) is problematic. I would not disagree with you that reference within XML is overall problematic, and ID and IDREF are far from ideal. Until a decisive advance seems clearly evident, ebXML CPPA and BPSS mechanics are retaining references mainly using ID/IDREF. If you think that there should be a change, we should mark that as an issue but probably for the 3.0 versions of the ebXML specifications (which are for CPPA and BPSS, many months away from active discussion) .
  2. BPSS instances don’t have target namespaces at the moment, at least in the xml sense of the term. An instance will mainly be in the BPSS namespace but might import stuff from other namespaces. The identifiers (such as the uuid attribute) are just URIs to identify the instance. Maybe we should give your proposal explicit attention in CPPA and BPSS. Could you provide some more explanation why you think a target namespace would be useful? [This may get back to your qname interest, but remember that unlike wsdl or schema, cppa and bpss have not bought into qname for reference….
  3. I do agree that we need to rethink how BPSS, CPPA, and ebMS should realign their concepts of service, action, actioncontext, role, etc. The UMM did not really have much to say about these notions in a direct way IMO. Mainly ebMS required Service and Action and BPSS had Role. EbMS added Role values to its header, and CPPA had to struggle to say how values from BPSS mapped into ebMS values. The use of the BPSS uuid attribute for a service value will probably need to be abandoned because a choreography can weave together more than one service, and can even tie services in narrow senses (query-response) with “services” following other patterns, such as notification/event  or business data exchange processes. I am hoping that eventually exploring design patterns for distributed processes will result in clarifying the situation. At the present it is all fairly murky and muddy. The ebSOA initiative may be useful. The w3c WS architecture was OK but with limited scope. If you have a model for us to consider, and you think it would help us enhance the current somewhat clunky alignment, by all means send it out.

 


From: Steve Capell [mailto:steve.capell@redwahoo.com]
Sent: Monday, November 01, 2004 12:07 AM
To: Dale Moberg; ebxml-cppa@lists.oasis-open.org
Cc: 'Monica J. Martin'; 'Harry Moyer'; 'Sacha Schlegel'
Subject: [ebxml-cppa] Comments on action & ActionContext

 

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:ActionContext

                    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: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Thursday, 28 October 2004 8:27 AM
To: ebxml-cppa@lists.oasis-open.org
Subject: [ebxml-cppa] OASIS ebXML CPPA core maintenance draft (2.1) and schema

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,

 

Dale Moberg

 

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]