ebxml-regrep message


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

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Re: Implicit CPP/CPA for Registry and Registry client


Assuming you include that terminology in the operating assumptions, I
suggest to take Scott N's suggestion and drop the terminilogy all together.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Farrukh Najmi <najmi@east.sun.com> on 04/04/2001 07:55:35 AM

To:   Scott Hinkelman/Austin/IBM@IBMUS
cc:   Farrukh Najmi <Farrukh.Najmi@Sun.COM>, "Nieman, Scott"
      <Scott.Nieman@NorstanConsulting.com>, "'ebxml-regrep@lists.ebxml.org
      '" <ebxml-regrep@lists.ebxml.org>
Subject:  Re: Implicit CPP/CPA for Registry and Registry client



Scott,

As state in my earlier email

> This has been the operating assumption as recently as our meetings last
> week.
> Please discuss this now if there are different opinions on this.

Operating assumptions have been known to be wrong. We very much need to get
any
issues on this resolved. The choice needs to be ours as a team. So your
thoughts on the subject would be quite helpful.

Scott Hinkelman wrote:

> Farrukh,
> I merely provided the roots of this terminology. I will not debate your
> choice of what to do with it.
>
> Scott Hinkelman, Senior Software Engineer
> XML Industry Enablement
> IBM e-business Standards Strategy
> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> srh@us.ibm.com, Fax: 512-838-1074
>
> Farrukh Najmi <najmi@east.sun.com> on 04/04/2001 07:46:04 AM
>
> To:   Scott Hinkelman/Austin/IBM@IBMUS
> cc:   Farrukh Najmi <Farrukh.Najmi@Sun.COM>, "Nieman, Scott"
>       <Scott.Nieman@NorstanConsulting.com>,
"'ebxml-regrep@lists.ebxml.org
>       '" <ebxml-regrep@lists.ebxml.org>
> Subject:  Re: Implicit CPP/CPA for Registry and Registry client
>
> Scott,
>
> The CPP/CPA I am working on is a template as opposed to actual one. The
> registry does not require any CPA negotiation for clients to interact
with
> it.
> The purpose of the CPP/CPA in teh spec would be to tell clients and
> registries
> what is expeted of them (e.g. what BP processes they must implement
etc.).
> There is no requirement that a client or a service actually use a CPP or
> CPA.
> Thus I feel this is implicit and not explicit by your own definitions.
>
> Note that the registry of registries case is special since in that case
it
> is
> likely that each registry would register its own explicit CPP in the
> registry
> of registries. However, a client is free to use an implicit CPP for a
> registry
> by simply plugging in the registry URI in the implicit CPP.
>
> Scott Hinkelman wrote:
>
> > Terminology issue. The word 'Implicit CPA' came from original
discussions
> > we had in TRP, where some folks believe that there does not have to be
an
> > explicit CPA to use TRP byitself (I support this in theory also). What
> you
> > are working on is an Explicit CPA template.
> >
> > Scott Hinkelman, Senior Software Engineer
> > XML Industry Enablement
> > IBM e-business Standards Strategy
> > 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> > srh@us.ibm.com, Fax: 512-838-1074
> >
> > Farrukh Najmi <najmi@east.sun.com> on 04/04/2001 07:30:47 AM
> >
> > To:   "Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>
> > cc:   "'Farrukh Najmi '" <Farrukh.Najmi@Sun.COM>,
> >       "'ebxml-regrep@lists.ebxml.org '" <ebxml-regrep@lists.ebxml.org>
> > Subject:  Re: Implicit CPP/CPA for Registry and Registry client
> >
> > By implicit I mean that there is no need for a negotiated CPA.
Negotiated
> > CPA
> > between registry and client is a valid but more advanced need IMHO. It
> > seems
> > adeqauet for now to spec the template CPP/CPA in the registry specs and
> > expect
> > that individual clients will fill in the URL etc. for the registry and
be
> > able
> > to do interactions with it as deined by RS spec and the BP
specification
> > schema
> > that will be added to it by end of next week.
> >
> > This has been the operating assumption as recently as our meetings last
> > week.
> > Please discuss this now if there are different opinions on this.
> >
> > "Nieman, Scott" wrote:
> >
> > > Farrukh,
> > >
> > > Help me out on this one.
> > >
> > > If you are basing the CPP/CPA on the TP/BP work, would not this be an
> > > "explicit" CPP/CPA, which is what I have been suggesting for a while?
> > > Implicit suggests that the physical CPP does not exist, but is
implied.
> > >
> > > im·plic·it (m-plst) adj. Implied or understood though not directly
> > expressed
> > >
> > > I really believe the physical CPP must exist to understand the
> > capabilities
> > > of a registry.
> > >
> > > Scott
> > >
> > > -----Original Message-----
> > > From: Farrukh Najmi
> > > To: ebxml-regrep@lists.ebxml.org
> > > Sent: 4/4/01 6:47 AM
> > > Subject: Implicit CPP/CPA for Registry and Registry client
> > >
> > > I wanted to remind the team that I am working on an action item from
> our
> > > last meeting to re-introduce the implicit CPP/CPA for the registry
and
> > > registry client. These were removed from the spec when we got
woefully
> > > out of date with the TP teams specs. My action item is to bring them
> > > up-to-date with current TP and BP specs.
> > >
> > > So yes the registry will have an implicit template CPP in the spec
> > > defined in terms of the TP and BP specs as will the registry client.
> The
> > > two CPPs will be used in much the same way as 2 parties that wish to
> > > conduct eBuisness together. This has always been the intent of our
> > > specs.
> > >
> > > --
> > > Regards,
> > > Farrukh
> > >
> > >  <<Card for Farrukh Najmi>>
> >
> > --
> > Regards,
> > Farrukh
>
> --
> Regards,
> Farrukh

--
Regards,
Farrukh







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC