Dieter Gawlick
Cecile Madsen
Vijay Dialani
Chris Kantarjiev (minutes)
Steve Fisher
Abdeslem Djaoui
Shailendra Mishra

Regrets: Susan Malaika

OASIS meeting going on this week; Discussion today is WS-Notification;
Susan is representing our interests publicly...

Problem for us is that the policies of WSN are not written down or
fixed, so it is difficult to understand exactly what the system is and does.

It appears that WSN is starting to think about some of the INFOD issues,
like the "spam model" and continuous queries.

If they produce something basic but sufficient, we will be able to
put in the extensions we want as policies...

Abdeslem's paper: Questions/clarifications...

- User can specify the schema of the data he wants to publish at any time;
you don't want to have a static schema.

- Producers are publishing one or more kinds of tables, but for each
table, you basically end up with a view/selection that covers the
projection/selection? of the data.

- Is the intent to do vertical or horizontal selection? Either. We agree
that there is a language that we can use to describe this.

- For events, something else is needed - a state change, rather than
just a descriptive language. A partitioning predicate doesn't seem
to be sufficient to describe that.

But is the event published? One view has it that the event is always
published, for opaque reasons, and the consumer is looking into the
set of events that have been published. The other view is that events to be published must be specified in a declarative
 way, and nothing will be published that has not been so specified.

- It might be an interesting exercise to try to map INFOD to the
OGSA producer interface, just to get our terms consistent.
Abdeslem thinks that we're not quite ready to do that yet; see below for more on this topic (and a todo item).

Moving on to INFOD spec:

- Would be nice to separate the services for producing and consuming
into two different portTypes, so different services could implement
only the piece that they're interested.

- Should be able to query & subscribe to a data source if the source
is a database, that should look like DAIS. It may be that we need
to revisit that and figure out a way to move away from being strictly
an extension of dataService in order to subscribe to an application...

- We should figure out how to describe this all as interfaces, each
interface corresponding to a particular capability, and allow individual
applications to figure out how to map a particular capability into
a service... but what is an "interface"? Oh, it corresponds to a portType.
In WSDL 1.1, you cut and paste, but it allows you to implement
different subsets of the functionality. The next version of WSDL
will do this better.

- We could take the sub portTypes and elevate them to full-fledged
portTypes, each representing a certain capability.

- Strawman: (publication, subscription & propogation), possibly
consumption in a single portType? But how is this very different from
what's in the spec? And it seems that there are other splits/combinations
that make sense as well, so the challenge is to come up with a
partition that works well.

* Shailendra & Chris will take the action item to work on this.

- Concern is that having to implement *everything* will limit the
usefulness.

- Comment: the spec is really hard to read, perhaps harder than necessary.
Not entirely clear how to fix it at the moment!

- Comment: is the document "just" a rule definition document? What
rule language do we really want to use?

- Comment: it seems much to early to be updating the document, since
we are only just starting the discussion...

portType arrangement, rule language, discovery for next time -
that's more than one call! But those seem to be the three threads
of interest at the moment.

* Abdeslem will circulate a portType strawman for the next call....

Next call in two weeks.