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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Negotiation problem


"univoque" seems to be a neologism I just coined ... (I checked in babelfish
and did not find it!!!)
I meant "a unique way"

/Stefano

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: 31 January 2001 14:07
> To: ebxml-poc@lists.ebxml.org
> Cc: ebxml-tp@lists.ebxml.org; ebxml-transport@lists.ebxml.org
> Subject: Re: Negotiation problem
>
>
> I concur with Stefano's observations with one caveat...
> what is univoque?
>
> Cheers,
>
> Chris ;-)
>
> Stefano POGLIANI wrote:
> >
> > Michael,
> >
> >         pls find my comments embedded.
> > Best regards
> > /stefano
> >
> > > -----Original Message-----
> > > From: Michael Joya [mailto:mike.joya@xmlglobal.com]
> > > Sent: 31 January 2001 01:14
> > > To: Stefano POGLIANI
> > > Cc: ebxml-poc@lists.ebxml.org
> > > Subject: Re: Negotiation problem
> > >
> > >
> > > Stefano POGLIANI wrote:
> > >
> > > >         There is a SINGLE CPA that is negotiated by the two parties.
> > > >         Let's take the simple case of two parties stating
> they support
> > one BP (it
> > > >         will be simple to extend to multiple BPs).
> > >
> > > >        The CPP of PartyA references the
> BP_Sell_The_Flowers. The CPP of
> > PartyB also
> > > >         references the BP_SellThe_Flowers. PartyA and
> PartyB negotiate
> > ONE CPA.
> > > >         Your (2) (which says, if I am correct "The Respondant must
> > calculate the exact
> > > >         same CPA as her potential client") is improbable in
> the sense
> > that there is
> > > >         only one CPA
> > >
> > >   I understand that only one CPA exists between the two parties
> > > for a given BP. The problems I face are:
> > >
> > > a) who authors it?
> >
> >         So far, this is not perceived as an issue.
> >         It is not important who is going to author it, but what
> will the CPA
> >         contains and which format will it portray.
> >
> >         As far as I am concerned, I would like (obviously) to
> have/build a tool
> >         which would be able to properly deal with the following:
> >         - editing/displaying CPPs
> >         - editing/displaying CPA
> >         - helping in composing a CPA from two CPPs (drag/drop, automatic
> >           verification of compatibilities etc)
> >
> >         As someone (Marty I think) pointed out recently, it
> will be very difficult
> >         to think that a CPA can be "generated" in an univoque
> way; I personally
> >         think that a tool may help in composing a CPA but human
> intervention
> >         will be required, at least up until there will be more
> knowledge on the
> > topic.
> >
> >         This does not mean that there is no format for the CPA,
> of course. But that
> >         there "may" be many ways to express the same concept or
> there may be
> > variants
> >         that cannot easily be picked up automatically
> >
> > > b) how does the non-authoring party come into possession of it?
> >
> >         As far as I understand today, the two parties will work
> off-line to
> >         cooperatively build/compose the CPA.
> >         Fax, e-mail, snail-mail, phone...
> >
> >         I think that, as someone already pointed out, automatic
> negotiation of
> >         the CPA is not currently the most critical issue, nor
> it is a showstopper.
> >         Once the CPA format is known and once the relationships
> between the
> >         CPA tags and the two-CPPs tags will be explained, one
> could arrive to
> >         the CPA itself. Someone could say: well, but this will
> be laborious and
> >         there is no grant that the process is univoque. I may agree, but
> >         unless the CPA specs will prevent people from
> understanding how the
> >         CPA content is derived from the CPPs contents, then it
> will be fine
> >         for the infrastructure release.
> >
> > >
> > >   Option 2 infers that both parties have with the same BP and CPP
> > > documents to start off with. They each create (independently)
> identical
> > copies of
> > > the same CPA document.
> > >
> > >
> >         I do not think that "creating identical copies" is the
> best approach.
> >         It is not impossible, though, and nothing in the CPA
> specs will prevent
> > this from
> >         happening. But it seems to me (personal consideration)
> the longest way to
> >         reach the result.
> >
> > >
> > > PS: My most recent copy of the CPP&A Specification is v0.1 dated
> > > 01/15/01. Is this up to date?
> >
> >         The latest should be V0.29
> >
> > >
> > >
> > >
> > > --
> > > // Michael Joya
> > > // XML Global Research and Development
> > > // 1818 Cornwall Ave. Suite 9
> > > // Vancouver, Canada
> > > // 604-717-1100x230
> > >
> > >
> > >
> > >
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC