Continuation of discussion from today's call

We ran out of time to conclude on two points:

a) what is the signature of the Evidence interface?
b) how are underlying PropertyNames to be supported?

The important thing is to resolve this TODAY so we can have a
substantive draft for discussion in Seoul next week, following which we
will issue a First Public Working Draft which "with a fair wind and a
following sea" (colloq. = with luck) will also be a Last Call working
draft.

We also need to have debate on this list as to the wording of the
remaining sections of the document.

Let's fix the interface first.

a) Evidence interface

The Resolution we nearly took was 

PROPOSED RESOLUTION: The Evidence interface is void put(String key,
String value) and that we provide a factory method on SimpleService

The reasoning is as follows:

The caller needs a way to put evidence into a known object in a
standardised way. The API must support HTTP Evidence in the form of
(case insensitive) HTTP Header Field name and (case sensitive) HTTP
Header Field value, both strings (ASCII stings, actually, but, er, let's
leave that point aside unless we have to).

It is likely that most Java implementations will want to allow the
passing of a HashMap<String, String> derived directly e.g. from the jsp
infrastructure, and we COULD mandate this in the Java binding. However,
in general this doesn't work as we can't rely on support of a
HashMap<String, String> structure in other environments/languages.

So a second 

PROPSOED RESOLUTION: In the Java interface we mandate that Evidence
subclasses HashMap<String, String>

It ought also to be a documentation and conformance point that HTTP
Header Field names are treated case insensitively.

And the third resolution I have in mind is that we call this
SimpleEvidence (or HTTP Evidence) to distinguish it from any other sort
of evidence.

PROPOSED RESOLUTION: Rename Evidence to SimpleEvidence

b) Support for Property Terms distinct from PropertyRefs

Rotan has discussed this in clear terms that I could not hope to match
[1].

In essence we have 2 proposals, Rotan's which is to overload the
semantic of PropertyRef so it can be aspectless, and mine, which is to
keep the PropertyName class and add a couple of factory methods - one to
PropertyName and the other to SimplePropertyValue, so we don't have to
refer to any inheritance relationships between them.

PROPOSED RESOLUTION ALERNATIVE 1: Add a method to SimpleService
SimplePropertyValue  getPropertyValue(Evidence e, String aspect,
SimplePropertyRef propertyRef) where the aspect parameter overrides
whatever aspect is present in the propertyRef and throw exceptions
appropriately

PROPOSED RESOLUTION ALTERNATIVE 2: PropertyName remains in the API and
can be constructed from a PropertyRef by a factory method and that a
PropertyRef can be created from a PropertyName by a factory method
naming the aspect.


Additional proposed resolutions

PROPOSED RESOLUTION: In SimplePropertyRef rename getName to
getPropertyName

PROPOSED RESOLUTION: In SimplePropertyRef rename getAspect to
getAspectName 

PROPOSED RESOLUTION: In SimpleService rename newPropertyRef methods to
newSimplePropertyRef   


That's it folks - pls send +1s etc. to this list asap

Jo

Received on Monday, 25 February 2008 15:10:39 UTC