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.