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

a:
PROPOSED RESOLUTION A: +1

PROPOSED RESOLUTION B: +1

b: 
PROPOSED RESOLUTION C ALERNATIVE 1: -1

PROPOSED RESOLUTION C ALTERNATIVE 2: +1

c:
  +1 for all

/Pontus
 

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Jo Rabin
Sent: den 26 februari 2008 08:53
To: public-ddwg@w3.org
Subject: Final chance, for now, to offer opinion on Simple API [was
Continuation of discussion from today's call]


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.

Jo

Contents:

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

Urgency:

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

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

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

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
[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 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
appropriately

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


c) Additional proposed resolutions

PROPOSED RESOLUTION D: In SimplePropertyRef rename getName to
getPropertyName

PROPOSED RESOLUTION E: In SimplePropertyRef rename getAspect to
getAspectName 

PROPOSED RESOLUTION F: In SimpleService rename newPropertyRef methods to
newSimplePropertyRef   


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

Jo

Received on Tuesday, 26 February 2008 10:09:06 UTC