Resolutions from the November F2F

We took quite a number of resolutions at the recent F2F. Here is a
summary from the three days of meetings, in the order in which they were
taken. 



= = = = = = 8 November 2007

RESOLUTION: We will not define Constructors via an Extension to IDL

RESOLUTION: The basic Class Model is that every class (other than
factory classes) has an accompanying factory class, plus set methods and
a clone method, in some cases the set and clone methods will not have
public scope

RESOLUTION: Default namespace is none (nothing will work) but the
instantiation of the DDR must provide for setting of the default
namespace - which cannot subsequently be changed

RESOLUTION: getProperty method will return an object that can be queried
(rather than requiring a separate method that requires specification of
units) (as contrasted with returning a simple type)

RESOLUTION: We support reference to properties by strings containing
names (which we have yet to decide will be namespace prefixed)



= = = = = = 9 November 2007

RESOLUTION: The DDR Service and Recognition Classes are instantiated
separately from each other

RESOLUTION: The basic Class Model is that every class (other than
factory classes) has an accompanying factory method (possibly of more
than one class), plus set methods and a clone method, in some cases the
set and clone methods will not have public scope

RESOLUTION: The API methods will include signatures gPV(P,C); gPV(P,K);
gPV(P,K,A); gPV("P",C); gPV("P",K); gPV("P",K,A); getComponents(K,A)
where gPV is getPropertyValue, P is a property, K is a key, A is an
Aspect as detailed in the minutes. gPV returns a Value object,
getComponents returns an array of Components. "P" is string equiv of P.
(This resolution was further refined on 10 November.)

RESOLUTION: The return value of getComponents is an unordered set.

RESOLUTION: getDefaultComponent(k,A) and getCurrentComponent(k,A)
methods are part of the ddr class.

RESOLUTION: In java and other languages that support such constructs
(for each etc) any DDR API collection class supports the interface
Iterable (or whatever is needed in that language)

RESOLUTION: There will be two methods to get propertyValue. For example
ddr.getPropertyValue(propertyFactory.createProperty("resolution"), key);
and ddr.getPropertyValue("resolution", key); The second method uses the
default vocabulary defined in the DDR class constructor.
(This resolution was further refined on 10 November.)



= = = = = = 10 November 2007

RESOLUTION: Brand and Model will be supported as properties like any
other - and can apply to a number of different aspects of the delivery
context, implementations will have to deal with resulting ambiguity in
similar way to other ambiguous situations that must be dealt with

RESOLUTION: To accept the five methods pasted at
http://www.w3.org/2007/11/10-ddwg-irc#T17-01-58
Namely the following that were explained by way of an example of how to
retrieve the width of the screen:
    Set x = ddr.getPropertyValueSet("width", "screen", key);
    Set x = ddr.getPropertyValueSet("width", key); //for ALL
aspects/components
    Set x =
ddr.getPropertyValueSet(propertyFactory.createProperty("ddrns",
"width"), "screen", key);
    Set x =
ddr.getPropertyValueSet(propertyFactory.createProperty("ddrns",
"width"), key); //for ALL aspects/components
    PropertyValue v = ddr.getPropertyValue("width", key); // default
aspect, current/default component (authoring time, key would be defined)

RESOLUTION: A subset of the group will make arrangements for joint work
on the API code over the next few weeks with the intent to publish a
draft by the end of the year.



---Rotan