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

a)

 Res.A   "conditioned +1" to factory method for evidence objects with the following punctualizations / amendments:

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

Evidence = SimpleService.newEvidence()

In the "possible normative" Java binding We could have a 

SimpleService.newEvidence(Map) that will allow to create an Evidence object that it is a copy of the key-value pairs of that Map, making key.toString() and value.toString()

Note that I'm not in favour of using Map<String,String> as it would bound us to Java 1.5 and up and I would like to mantain compatibility with at least Java 1.4

Res.B +1 to Simple API having SimpleEvidence object (instead of generic 
Evidence)

b)Res.C(1) -1 as the proposal was only made as a backup if we decided to
remove PropertyName

  Res.C(2) +1 to keep PropertyName, factory method, and use in
SimplePropertyRef constructor.

c)

  D +1
  E +1
  F +1

Best Wishes

Jo Rabin escribió:
> 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:19:48 UTC