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

RE: 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 10:44:52 -0000
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B4C4A988@mtldsvr01.DotMobi.local>
To: <jmcf@tid.es>
Cc: <public-ddwg@w3.org>

I see that both Rotan and you are looking for and elaboration of Resolution C(2):

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

For the sake of clarity, are you saying that the only constructor should be of this form or are you saying that you'd like that in addition. The first interpretation is inconsistent with the decision to provide overloaded methods that have only Strings.

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.

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

Thanks for pointing that out. I agree. The proposed change is 

HashMap<String, String> => Map

Jo


> -----Original Message-----
> From: jmcf@tid.es [mailto:jmcf@tid.es]
> Sent: 26 February 2008 10:21
> To: Jo Rabin
> 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]
> 
> 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:45:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 12:13:53 GMT