RE: Substitution (was) my communication with CPP team

[Tony Weida <TonyW@EDIFECS.COM>]

I believe it's important to consider the alterations at two levels:

1. What kinds of changes are being made, and
2. What kind of thing is being changed.

If a CPA can specify the alterations via XSLT transforms, then it can (1)
clearly document the agreed changes to a reference specification, and (2)
specify changes to BPSS document instances as well as instances of other
specifications.  Whether the alterations are simple parameter substitutions
or other transformations, the result is effectively a new instance document
that must be valid according to the corresponding specification (and
reflects reality).  In practice, I'd expect the alterations to be made -- in
a suitably constrained manner -- using software tools which then emit the
appropriate XSLT.

Cheers,
Tony   


> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Tuesday, July 03, 2001 1:59 PM
> To: Karsten Riemer
> Cc: Tony Weida; James Bryce Clark; Karsten Riemer;
> ebxml-bp@lists.ebxml.org; ebxml-cppa@lists.oasis-open.org
> Subject: RE: Substitution (was) my communication with CPP team
> 
> 
> 
> Karsten,
> 
> I agree that an important question is what is being altered.   Giving
> values to parameters in the BPSS instance document is one thing.
> Wholesales substititution of pieces of the collaboration protocol is a
> different matter and will lead to all sorts of confusion when the BPSS
> instance document doesn't describe the actual collaboration 
> protocol.  I
> believe that changes of that magnitude should result in a new 
> BPSS document
> that reflects reality.
> 
> Regards,
> Marty
> 
> **************************************************************
> ***********************
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> **************************************************************
> ***********************
> 
> 
> 
> Karsten Riemer <Karsten.Riemer@sun.com> on 07/03/2001 12:04:40 PM
> 
> Please respond to Karsten Riemer <Karsten.Riemer@sun.com>
> 
> To:   Tony Weida <TonyW@EDIFECS.COM>
> cc:   James Bryce Clark <jamie.clark@mmiec.com>, Karsten Riemer
>       <Karsten.Riemer@sun.com>, ebxml-bp@lists.ebxml.org,
>       ebxml-cppa@lists.oasis-open.org
> Subject:  RE: Substitution (was) my communication with CPP team
> 
> 
> Hi Tony,
> I believe XSLT would work just fine. It is in fact a generic 
> substitution
> and
> alteration mechanism for XML. The substitution mechanism in 
> BPSS (added at
> Vienna) works on the same principle as XSLT, but is intended 
> to work on two
> specific aspects of a BPSS: The document type, and the transaction
> parameters
> (such as timeouts and security parameters). So we are looking 
> at a totally
> generic, free-for all, substitution mechanism (XSLT), and a 
> constrained
> one.
> Perhaps the answer lies somewhere in between. One question to 
> consider is
> how
> much can you substitute/alter before you are in effect creating a new
> process,
> rather than a parameterized instance of the standard process. I look
> forward
> to discussing this at the CPP face-to-face.
> 
> Note that I am making these comments as a CPP team member, not as an
> official
> spokesman for the BP team.
> 
> thanks,
> -karsten
> 
> 
> >I've previously suggested using XSLT to specify (and 
> document) how the
> >parties to a CPA have agreed to customize an external BP for 
> the purposes
> of
> >their specific agreement, while preserving the link to the original
> version.
> >XML DSIG provides mechanisms for the parties to sign over 
> the (transformed
> >version of the) BP in the process of signing the CPA.  The 
> ebXML Trading
> >Partners team agreed to table this topic due to lack of time 
> for working
> >through the details before the final meeting in Vienna.  I 
> certainly hope
> to
> >pursue this topic in the context of the new OASIS 
> Collaboration Protocol
> >Profile and Agreement TC.
> >
> >Cheers,
> >Tony Weida
> >Edifecs
> >
> >> -----Original Message-----
> >> From: James Bryce Clark [mailto:jamie.clark@mmiec.com]
> >> Sent: Monday, July 02, 2001 6:31 PM
> >> To: Karsten Riemer
> >> Cc: ebxml-bp@lists.ebxml.org; dmoberg@cyclonecommerce.com;
> >> mwsachs@us.ibm.com
> >> Subject: Substitution (was) my communication with CPP team
> >>
> >>
> >> At 12:42 PM 6/29/01, you wrote:
> >>
> >> >1. Use of the 'substitution' capability. What I mean by that
> >> is that a CPA
> >> >could 'substitute' parts of a BP by explicit agreement by
> >> the two parties.
> >> >They need a way to express such a substitution.
> >>
> >> My thanks to Karsten for pointing this issue out.  A similar
> >> issue came up,
> >> briefly, in March or April in Marty Sachs' old "TPA" group.
> >> I think this
> >> is a hugely important issue -- the extent to which trading
> >> partners and
> >> perhaps third parties can customize, or conversely rely
> >> (unseen) on the
> >> business process integrity, of a given defined transaction,
> >> and the extent
> >> to which it must be reflected or picked up somehow in
> >> artifacts derived
> >> from the CPA.
> >>
> >> I plan to follow this and probably kibitz loudly in the OASIS CPPA
> >> group.  It belongs there, not here, although it is a strong
> >> dependency of
> >> BP upon the CPA.  Just wanted to mention it "here" (BP) by 
> way of FYI.
> >>
> >> ,  Pe mgI mention it here only because there nmay be other BP
> >> people who d
> >> can CPPA c imilar question I thikn it
> >>
> >>
> >> ------------------------------------------------------------------
> >> To unsubscribe from this elist send a message with the single word
> >> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
> >>
> 
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
> 
> 
> 
>