RE: Final chance, for now, to offer opinion on Simple API [was Continuation of discussion from today's call]

We're back to the extensibility question surrounding the use of the
Evidence interface. Let me see if I can summarise:

1. We want the Simple API to support out-of-the-box the use of HTTP
headers as contextual evidence.

2. Some of us want to be able to extend the evidence to support more
complex data, while having a minimal impact on the Simple API.

3. It is possible that we could have general support for message
headers, rather than insisting that the headers must come from a HTTP
interaction with a client. But in this case we would need a way in the
evidence to indicate that we were dealing with HTTP or something else.

4. Even if we limit ourselves to just HTTP, individual implementations
will probably want to extend the support for evidence to other sources
with minimal impact on the API.

So, let's suppose that the Simple API only supports HTTP headers. Let's
also suppose that the SimpleEvidence class has putHeader/getHeader
methods (rather than putHTTPHeader/getHTTPHeader).

Now le'ts suppose that a custom implementation wants to provide more
than the Simple API, so that WSP can be supported. This custom
implementation is free to provide an additional evidence factory:
  Evidence newWSPEvidence(Map)

Note that it still provides an Evidence result, but also note that
hidden inside the returned instance is a flag that says "these headers
are WSP".

Later, the evidence instance is passed as a parameter in one of the
query methods. As this is all happening in the same implementation, we
can assume that the query knows to look inside the evidence for the
hidden "these headers are WSP".

So, with this extra custom factory, we have extended the Simple API to
support WSP and none of the rest of the Simple API has been affected in
any way.

Because of this non-destructive possibility of extending the Simple API
in custom solutions, I'd agree to the suggested names of putHeader and
getHeader. Of course, it would be quite reasonable to demand that if the
Simple API factory "newSimpleEvidence(Map)" is used, then these
putHeader/getHeader methods *must* be interpreted to mean HTTP headers.
If you choose to use a custom factory, those methods can refer to
anything you like.

In a nutshell: off-the-shelf, Evidence supports HTTP headers, and if an
instance of Evidence is produced via the
SimpleService.newSimpleEvidence(Map) then the instance must only deal
with HTTP headers.

This leads me to think perhaps that the name of the factory needs to be
changed to newHTTPEvidence(Map), while the interface name itself can
still be SimpleEvidence.

---Rotan.



-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Jo Rabin
Sent: 26 February 2008 10:45
To: jmcf@tid.es
Cc: public-ddwg@w3.org
Subject: RE: Final chance, for now, to offer opinion on Simple API [was
Continuation of discussion from today's call]

[...]

Also, 

> + the methods should be called putHeader and getHeader to avoid
binding it
> to explictly to HTTP (why it cannot be used with WSP, for example)
> + the factory method in IDL should not receive any parameter i.e.
>

I thought that our intention was to provide normative means of using
HTTP headers as evidence. I don't quite understand how one would
implement something that allowed any Name / Value pair unless one knew
what domain the name / value pair came from. For example, the name /
value pairs might be property names and values. However, that's beyond
the scope of what we agreed for the simple API. Implementations might
choose to implement that sort of evidence but that's not our concern. 

It seems to me that the intention is that ALL conforming implementations
implement HTTP headers. We can certainly add to the list of name value
pair types that must be supported but better make that suggestion very
soon. Also make suggestion as to how to disambiguate HTTP headers as
evdience from anything else.

[...]

Received on Tuesday, 26 February 2008 12:10:47 UTC