W3C home > Mailing lists > Public > public-ddwg@w3.org > February 2008

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

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 26 Feb 2008 07:53:15 -0000
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B4C4A94B@mtldsvr01.DotMobi.local>
To: <public-ddwg@w3.org>

What follows is an edited version of what I sent yesterday. Apologies
for sending it to the wrong list initially.

Aside from Rotan there have been no contributions. For the sake of
getting a document ready for the Face to Face I am going to start work
later this afternoon on a draft. In the absence of response I will take
it as a "+1" to all resolutions except C Alternative 1.



a) what is the signature of the Evidence interface?
b) how are underlying PropertyNames to be supported?
c) Misc renames for consistency


The important thing is to resolve this TODAY [that was yesterday] 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

Other Tasks

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


Let's fix the interface first.

a) Evidence interface

PROPOSED RESOLUTION A: The Evidence interface is 

void putHTTPHeader(String headerName, String value) 
String getHTTPHeader(String headerName);
Boolean headerExists(String headerName);

A factory method is added to SimpleService:

Evidence newEvidence(HashMap<String, String> httpHeaders)

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).

The retrieval methods are there so that an object created by some other
instantiation method can still be queried by the any implementation,
although that might not be very efficiently, it does allow inter

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. 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 the factory method will probably look different in the

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

I think we should call this SimpleEvidence (or HTTPEvidence) to
distinguish it from any other sort of evidence.

PROPOSED RESOLUTION B: 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

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 C 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

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

c) Additional proposed resolutions

PROPOSED RESOLUTION D: In SimplePropertyRef rename getName to

PROPOSED RESOLUTION E: In SimplePropertyRef rename getAspect to

PROPOSED RESOLUTION F: In SimpleService rename newPropertyRef methods to

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

Received on Tuesday, 26 February 2008 07:53:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:15 UTC