Next in thread → Next in month →

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

From
David RR Webber \(XML\) <>
Date
2006-05-24T16:04:52+00:00
ID
Thread
RE: [ebxml-cppa] SimpleCPA [was RE: [ebxml-cppa] Issue: should BusinessTransactionCharacteristics be made zero or one in future CPPA schemas (v 2.1 and 3.x)]
Pim,

 

Yes!  I like it.

 

This has all kinds of applications in creating templatable CPA's
where people can just externally provide some references and key parts
- such as their cert, partner ID and URLs - and the rest would be
all pre-packaged in the CPA template.

 

That would indeed be very powerful.

 

DW

-------- Original Message --------
Subject:
[ebxml-cppa] SimpleCPA [was RE: [ebxml-cppa] Issue:
should
BusinessTransactionCharacteristics be made zero or one in
future CPPA
schemas (v 2.1 and 3.x)]
From: "Pim van der Eijk"
<>
Date: Wed, May 24, 2006 10:23
am
To: "'OASIS ebXML CPPA TC'"
<>

 

[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
Next in thread → Next in month →