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

RE: Continuation of discussion from today's call

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Mon, 25 Feb 2008 10:30:24 -0500
Message-ID: <D5306DC72D165F488F56A9E43F2045D3017E2C15@FTO.mobileaware.com>
To: <public-ddwg@w3.org>

[Replying on DD list, due to accidental misdirection.]

My proposed solution of overloading the semantics of SimplePropertyRef
was to illustrate that there is a way forward without having a
PropertyName class, if we would like to remove it as we did with the
AspectName class.

In fact, I'm happy with either approach. Overload SimplePropertyRef, or
retain the PropertyName class and provide a suitable factory for it. In
both cases I expect that there are methods involving classes in queries,
other than strings. The methods that only use strings are not type safe
and would only be for limited simple use cases where performance is not
an issue. Generally I would be recommending the methods that use typed
(non-string) parameters.

So I give +1 to both alternatives, and will wait to see if there is some
other opinion/argument why it should be otherwise. (Keeping PropertyName
does seem to me to be perhaps the easier route.)

(I'll comment on Evidence in my next message.)

---Rotan


-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Jo Rabin
Sent: 25 February 2008 15:10
To: public-bpwg@w3.org
Subject: 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:30:37 GMT

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