Sacha,
Contrary-wise - I would not need to send you those includes if they
are standard pieces already! ; -)
And / or available on a URL that you can reach...
And of course - you can still in-line those parts you need to have
localized.
The only issue with xinclude is the breadth of parser support
for it - I've not checked
recently - but previously the parsers were shying away from
supporting it...?
Of course - having <include/> mechanism in CPA
itself means that CPA processors need to implement that - even
though its trivial function call.
I think the issue with xinclude is that it can be recursive and other
wild things - that's why the parsers are nervous to implement it.
Obviously we can restrict in the CPA spec' how someone can use the
xinclude to just a sub-set - and also restrict levels of nesting and so
on.
DW
-------- Original Message --------
Subject: 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: Sacha Schlegel
<>
Date: Wed, May 24, 2006 10:39
am
To: Pim van der Eijk <>
Cc:
'OASIS ebXML CPPA TC' <>
Hi
Pim
I see your point.
At the same time one of the nice
things of the CPA, in my opinion, is
that everything IS in one
static file.
Eg if I have to email you the CPA, I can select one
file in my email
client no need to worry that I include all required
referenced files, eg
even with the correct directory structures if
we have the files locally.
Here I would need a CPA tool to only make
sure I send you all the
correct files. XInclude may add some more CPA
management challenges.
Having information not static in one file
may also add some dynamics
into CPA's, eg at one point I change a
cert.xml file and all of a sudden
ALL CPA's referencing that
cert.xml file reference a new cert when
reread.
Just some
thoughts ...
Sacha
On Wed, 2006-05-24 at 16:23 +0200, Pim
van der Eijk wrote:
>
> [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
---------------------------------------------------------------------
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
