RE: Strawman OPES Charter

On Tue, 13 Jul 2004, Abbie Barbir wrote:

> > Would it be appropriate to mention that the rules work will
> > be based on P language specification that WG has already
> > worked on? Or are we going to re-select among P, IRML, and
> > others as a starting point?
> >
> > If we are going to re-select, should we start with a
> > "language requirements" document?
> >
>
> obsultly, yes we should do a requirement document.

Abbie,

Just to make sure: which of the following you consider essential:

	a) forget about P choice, start from scratch, write a
	   formal "language requirements" document, then select among
	   IRML, P, and possibly other candidates.

	b) confirm past P choice, but write a "language requirements"
	   document or section, before proceeding with polishing P

	c) confirm P choice, and do not write a "language
	   requirements" document/section

> > 	- Defining an interface between rules language
> > 	  and service (at least OCP-speaking service)
> > 	  How to pass parameters to services? How to
> > 	  get the result of service application, including
> > 	  errors, back to the language/program?
> >
>
> this is a muddy situation. we can rely on other work or at least
> reference how they handel it (examples, BPEL, CDL etc..)

I think there is an important difference between reusing existing work
and not doing any work.

First, we need to decide whether we should define the said interface.
The first charter draft does not seem to include it. Iff we are
chartered to define the rules-services interface, then I would look at
reusing WSDL core for describing OCP-talking callout services and
describing a P:WSDL mapping of sorts (a BPEL equivalent for OPES?).
However, if we are not chartered to define the rules-services
interface, then WSDL and other W3C-technologies reuse becomes
irrelevant/future work.

It seems to me that we must have a P-services interface because
without it, how will P interpreters map service calls to OCP
transactions? How will they make service parameters available to P
programmers to set? Will P interpreters report service failures in a
consistent way across implementations? All these questions were
already on P and even IRML to-do list, IIRC.

If we decide to go down that path, the second question becomes whether
the P-services interface is OCP specific or more general? Do we want
to restrict P-invokable services to OCP-talking services? To any
WSDL-describable services? To something else? Should this important
decision be done now or after we finish the new charter. That is, do
we add the answer or just the action item to the charter?

> 1. Security for OCP, should we mention that the group might attempt
> to do that as part of the charter or not. It can be a MAY
> deleiverable.

I was under impression that we agreed that security is very important,
but we have not enough cycles to include it in the new charter. OCP
security features may be described in individual draft(s) that the WG
might adopt later, through a charter modification. Can you give me an
example wording for a "MAY deliver" of OCP security specs?

> 2. Need to ensure that IAB requirements are still applicable to any
> new protocol we address. This MUST be in the charter. Our previous
> work addressed the general acrhitcecture but has focused on HTTP.

Markus already has the following wording:

	As each deliverable is developed, it must address the
	IAB considerations specified in RFC 3238.

It seems sufficient to me. Do you want more text added?

Thanks,

Alex.