SimpleCPA [was RE: [ebxml-cppa] Issue: should BusinessTransactionCharacteristics be made zero or one in future CPPA schemas (v 2.1 and 3.x)]

[Nothing to do with BusinessTransactionCharacteristics, 
but responding to "SimpleCPA" suggestion] 

 

W3C XInclude (http://www.w3.org/TR/xinclude/) could 
support a lot of this without requiring incompatible extensions or CPA-specific 
functionality.  

It would ease hand-editing CPAs.  

 

The least human-reable parts of CPA, and among the ones 
most likely to change when building a CPA from a template, are the 
XML 
Dsig public key information elements. XInclude would allow one to write 
something like (exported certificate file name 
based on SerialNumber):

  

  <tns:Certificate 

   tns:certId="P1_SigningCert">

      <xi:include 
href="../Certs/192466156709589705231692271946384786091.xml" 
/>

  
</tns:Certificate>

 

Or even 
(exported certificate 
file name based on IssuerName): 

 

  <tns:Certificate 

   tns:certId="P1_SigningCert">

      <xi:include 
href="../Certs/CN=Partner A,O=Partner A.xml" />

  </tns:Certificate>

This would alleviate the CPA author from having to 
copy/paste exported signature information in CPA files.

This assumes the CPA import tool resolves the 
XInclude statements prior to compiling the CPA information to its internal 
data structures.

 

Pim

From: David RR Webber (XML) 
[mailto:] 
Sent: 23 May 2006 23:59
To: Dale 
Moberg
Cc: OASIS ebXML CPPA TC
Subject: RE: [ebxml-cppa] 
Issue: should BusinessTransactionCharacteristics be made zero or one in future 
CPPA schemas (v 2.1 and 3.x)

Dale,

 

Flattening, aka simplifying the CPPA / CPA would be a huge plus 
(SimpleCPA?!).  

 

Even though people use editors to build these things - making them easier 
to visualize would definately aid adoption and use.

 

The notion of taking two CPP's and gluing them together somehow to make a 
CPA is nevertheless fraught IMHO.  It's never really worked well - in part 
because of all the gnarly refID constructs to name one challenge.

 

Removing the BusinessTransactionCharacteristics 
completely would definately make it easier to align just the communications part 
of the arrangement.  You'd still need to retrofit your business 
transactions - but as you note - if you referenced a BPSS instead - that would 
provide the road map to those.

 

Also - establishing the notion of profiles and 
templates for common configuration sets, is another key need.

 

In fact - if we could somehow break the CPA down 
into more sub-atomic parts - that could be included....and also therefore making 
things more pluggable...

 

And I completely agree that retain 100% V2.0 
backward-ness is not a critical factor.

 

Just brainstorming here - and being completely 
radical -  I'd like to see something like this:

 

<CPA>

  <Header> <include 
location="/cpa/myheader-template.xml"/> </Header>

  <CommsSetup><include 
location="/cpa/tomcat/myComms-template.xml"/> 
</CommsSetup>

  <Security><include 
location="/cpa/ssl/mySSL-template.xml"/> </Security>

  <Transactions><include 
location="/cpa/UBL/myBPSS-trans-template.xml"/> 
</Transactions>

  <ErrorHandling><include 
location="/cpa/myHandler-template.xml"/> </ErrorHandling>

  <Signals><include 
location="/cpa/mySignals-template.xml"/> </Signals>

  <Extensions><include 
location="/wsdl/myExtensions-template.xml"/> </Extensions>

</CPA>

 

and of course each template would be reflect the 
original CPA syntax and stuff relating to each part.

 

Bit too radical?!?

 

DW

-------- 
  Original Message --------
Subject: [ebxml-cppa] Issue: should 
  BusinessTransactionCharacteristics
be made zero or one in future CPPA 
  schemas (v 2.1 and 3.x)
From: "Dale Moberg" 
  <>
Date: Tue, May 23, 2006 5:15 pm
To: 
  "OASIS ebXML CPPA TC" <>

  

  

  
Many months ago several people 
  (especially Hima) noted that BusinessTransactionCharacteristics is sometimes 
  unnecessary and in general can complicate the checks for an acceptable 
  compatibility between CPPs when forming a CPA.

  

  
When using BPSS (especially 2.0), 
  and when not changing any values from those in the BPSS instance, the 
  BusinessTransactionCharacteristics attributes end up repeating information in 
  the BPSS instance. In addition, the QOS parameters needed for a message 
  service are generally independently documented in specialized sections of the 
  DocExchange element or in the Transport, so the “abstract” features of the BTC 
  tend to just summarize the real configuration 
  details.

  

  
Since we are trying to wrap up 
  changes, errata, and ebMS 3.0 support in the CPPA specification, I would like 
  the TC to review this optionality issue and decide whether we should change 
  the cardinality to allow omission of the element when it is not really needed. 
  (and document when that is).

  

  
I recall this issue was raised 
  when considering how to flatten the XML hierarchy of CPPs and CPAs (which most 
  agree would make it simpler to read if not to use!). I think flattening could 
  be done but it would be a departure from conserving the structure of CPPA 2.0 
  instances. Since CPPA instances are probably headed toward being something 
  that are never “seen” in editors, but only imported and exported by software, 
  flattening is not something I have heard much about lately. If you think we 
  should reconsider this for the transition to committee draft from editor 
  draft, please discuss on the list.

  

  

  

  

  

  

--------------------------------------------------------------------- 
To unsubscribe from this mail list, you must leave the OASIS TC that generates 
this mail. You may a link to this group and all your TCs in OASIS at: 
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php