RE: [ebxml-cppa] recent discussions of context

[Martin W Sachs <mwsachs@us.ibm.com>]

Dale,

Some replies below.

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
*************************************************************************************



"Dale Moberg" <dmoberg@cyclonecommerce.com> on 02/05/2002 12:04:06 PM

To:    "Duane Nickull" <duane@xmlglobal.com>, Martin W
       Sachs/Watson/IBM@IBMUS
cc:    <ebxml-cppa@lists.oasis-open.org>
Subject:    RE: [ebxml-cppa] recent discussions of context



Marty and Duane,

Looking into context had been listed as a future work item
(past version 2.0x). The main software "consumer" of CPA
information has been the ebXML MSH software and maybe some
additional middleware modules concerned with things like
digital enveloping that are not yet in ebMS 2.0x.

It seems to me that the software module consumers
of context may be software more akin to
translators/transformers of payload information: what I think is, in
ebTWG lingo, the BOD to BIE to BOD flows/assembly/customization.
I think this complicates our underlying view of what module-maker
has the "knowledge" to 1. form draft CPAs from CPPs or CPA-templates
2. what module can carry out the negotiation of parameters
(are context parameters negotiable???) I realize that
we are already into this realm when overriding _some_
of the BP level parameters from a BPSS schema, but
we are moving in a direction that complicates the
underling rough boundaries of components. This is a
scope shift that I think should go up for a vote after
a motion is made in the TC. My procedural $.02 worth.

MWS:  I agree that this is a scope shift and we should formally
agree on it. I do not know of any other place to put this
information other than in the CPP/CPA (including "external"
appendages to them). Moving up in the hierarchy from plumbing
is, I think, not unexpected.

Next, and this is mainly for Marty,
is your objection to re-using PartyRef as a pointer
off to schemas for context information that we might
simultaneously need both the URI to variable company info
(like the administrative contact person's phone number)
as well as context?

MWS: The objection is specifically to putting the context
information into the "phone book" since the context
information is deployment information, not a volatile
list of contacts.

If so, 1. would changing the cardinality of
PartyRef suffice?

MWS:  It would suffice but I think that a different
element name, such as InternationalizationPolicy,
would be more understandable, since the purpose is
very different.

If not, and we introduced a new
element, what would the new ContextRef pointer
be like? That is, would it vary in an essential way from
the PartyRef?

MWS:  Grammatically, I suppose it could be the same as
for PartyRef.

Should we made a PartyRef.type and allowed
several elements (PartyRef included) to extend the type?

MWS:  This is possible also. But it is a somewhat bigger
change for version 2.0
than just adding a separate element for context.

We could do something like make another placeholder
for context and still stay within
the 2.0 version time frame if we can decide this within the
next 2 weeks.

MWS:  For sure, we can't do more than a placeholder for
the version we are working on.  We have the major question
of what kind of function belongs in the context document
and how to express it.





-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: Tuesday, February 05, 2002 12:58 AM
To: Martin W Sachs
Cc: ebxml-cppa@lists.oasis-open.org
Subject: Re: [ebxml-cppa] recent discussions of context


Marty:

I applaud your decision to start this work.  It is imperative for the
entire infrastructure that your team do this.

I can provide more detailed information of the context issue to whomever
follows up.

Duane


Martin W Sachs wrote:
>
> The recent discussions of context have centered around the PartyRef
> document as the source of context information. I am starting to think
that
> PartyRef is the wrong place for context information and that context
> information belongs in the CPP and CPA proper. In other words, Duane's
> "typo" (PartyInfo) may be the correct answer.
>
> The PartyRef document is intended to be nothing more than a "telephone
> directory" whose contents are likely to change at any time because of
> personnel changes or organizational changes. There is a specific
admonition
> in the CPPA Specification to dereference the pointer to PartyRef only
when
> the information is needed. I also note that last week, the CPPA team
agreed
> to add a schema location attribute to PartyRef.
>
> I believe that context information, and especially
internationalization
> information, will be, or will include, deployment information, which
is why
> it should be in the CPP and CPA themselves.   The context information
might
> also have to be negotiated. I don't know enough about
internationalization
> to understand exactly what would be included in a CPP or CPA but I
would
> imagine that at a mininum it would include a code for the Party's
> geographical region and perhaps internationalization policy
information
> which might include such things as which party is responsible for
> translating between two different geographical contexts.
>
> If someone who is watching this list is in a position to submit a
proposed
> definition of internationalization context, I urge the CPPA team to
> consider it.
>
> 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
>
************************************************************************
*************
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>