Re: Device Description definition

Hi Rhys,

>> the DDWG interfaces will deal only with characteristic properties in a repository. Other interfaces, such as DCI and OMA DPE, will deal with 'current' values of properties that could change

I think we need terms to distinguish between the fixed repository set, and the 'current' set, of attribute-values that form the device description:

When I use 'Device description' in the DDR Requirements doc, I would likely be referring to the repository set - i.e. the fixed properties. But I may need to refer to the current set, and make a consistent distinction. 'Delivery context' is not suitable because it incorporates non-device characteristics, so could we use 'Device description instance' for the current state of device values? A Device description instance would therefore be a subset of the delivery context. 

Cheers
Kevin

_______________________________________________
From: Rhys Lewis 
Sent: 28 February 2007 10:28
Subject: RE: Device Description definition

Hi Kevin, 

Actually, I don't think that device characteristics need to be limited to fixed properties. It's just that the DDWG interfaces will deal only with characteristic properties in a repository. Other interfaces, such as DCI and OMA DPE, will deal with 'current' values of properties that could change and that could involve interaction with the device itself. 

Sorry if I didn't make that clear.

I'd like to propose my wording as a possible solution. Delivery context is already described as
"A set of attributes that characterizes the capabilities of the access mechanism, the preferences of the user and other aspects of the context into which a web page is to be delivered."

My wording reuses that definition. Here is the reference to the public list entry
http://lists.w3.org/Archives/Public/public-ddwg/2007Feb/0028.html
 
The wording for the noun is the one I'm proposing.

Cheers
Rhys
________________________________

HI everyone,

Based on Rhys' point below, should we therefore hone Rotan's definition[1] to reflect a constraint of fixed properties only? Or is that implicit in the fact that the values apply to each member of the set?

Cheers
Kevin

[1] Device description - a collection of attribute-value pairs, adhering to a known vocabulary, that apply to each member of a set of devices
________________________________

From: Rhys Lewis
Sent: 28 February 2007 09:47
Subject: RE: Device Description definition


Hello everyone, 

In Jo's terminology and example, 'can have' is within the scope of DDWG while 'has' is in scope for DCI and OMA DPE. That's because DDWG is building a repository interface whereas DCI and DPE are dynamic interfaces.

I'm assuming here we are talking about characteristics whose properties can vary. Those that never do are clearly in DDWG scope. So 'has' for a fixed property is in DDWG scope.

Best wishes
Rhys

________________________________

From: Jo Rabin
Sent: 28 February 2007 09:22
Subject: RE: Device Description definition

Does this boil down to a discussion of the difference between "can be (have)" and "is (has)"?

XYZ screen orientation can have landscape/portrait - this XYZ is currently landscape.

P800 can have Opera/Obigo, this P800 has Opera.

The discussion on composing everything into "master configurations" vs a more granular approach, seems to me to be very similar to the discussion on categories e.g. 6630 is an S60 device therefore ... 

... however before we re-open that discussion J perhaps we should complete the discussion on terminology?

It seems to me that we have a number of candidates that need terms:

-          The properties of a particular device instance at a particular point in time. e.g. right now I am being accessed by a N73 using the Nokia browser and it is in portrait orientation - i.e. all the "can have"s have been resolved to "has".

-          The capabilities of a class of devices i.e. XYZs can  have ...

-          (Possibly) a narrower set of capabilities and properties half way between the two referring to referring to an instance.

So maybe we are saying that a capability is a list (or range) of values and that a property is a choice of value from the possible values. Then a device description is a collection of properties and their values. And I think we need a term for the collection of capabilties and their ranges. The categorization question is perhaps whether a capability can have other capability collections as values?

Jo
________________________________

From: Johan Hjelm (TO/NRJ) 
Sent: 28 February 2007 07:56
Subject: RE: Device Description definition

Or, you could want to do an adaption to a device, which would be done in a two-step process: First adapt to the (unchanging) hardware, then to the (changeable) software. 

Since, however, that would mean that possibility of changing the device would imply the same as having different software (in my last computer, I could choose between a DVD drive and an extra battery), and so would have to be taken into account. So the configuration that could be contained in a database would be an _absolute minimum_, and then you would have to take the specfics  of the device into account. Which makes the database pretty useless...

OR, you could have "master configurations" for the most reasonable/usual configurations, e.g. "P800 with Opera" and "P800 with Obigo". Or something like that. 

//Johan

________________________________

From: Jo Rabin 
Sent: Wednesday, February 28, 2007 4:47 PM
Subject: RE: Device Description definition

Ø       I am not sure how the user agent could not be known.

Ø       is when you are transmitting the information without a prior association (i.e. a broadcast - in all other cases, the data has to be preceeded either by a query or by an invitation)

Hmmm ... I think there is a reasonable use case where you want to know device capabilities without there being a specific device involved, i.e. the question of determining device capabilities can be independent of interaction with a specific device instance.

So I could be sitting in my arm-chair and saying - "what are the properties of the Device XYZ?" - and a useful answer might be "it has the following inherent properties ... and the rest of them are determined by the choice of User Agent, which as far as we know is as follows: Firefox, Safari ... and the following mods which as far as we know is as follows: paper tape reader, keyboard ...."

And likewise apologies if this is insipid or obvious.

Jo
________________________________

From: Johan Hjelm (TO/NRJ)
Sent: 28 February 2007 01:19
Subject: RE: Device Description definition

Based on experience, I would favor the second definition. There can be compound devices (e.g. a Teletype printer with a punch tape writer/reader attached could concievably be seen as a printer with storage, if it was addressable as one entity). As a matter of fact, this is a question of granularity - a computer can be seen as a processor with memory and display attached, and it may be meaningful to know the size and speed of the memory (but it may be irrelevant whether it is attached with SCSI or IDE). The "packaged" configurations from manufacturers is what is represented in the WURFL database and similar; the updates to these "packages" are what is represented by override capabilities and similar (and stuff like user preferences, and so on). 

I am not sure how the user agent could not be known. The data is either requested by an entity (in the device), or pushed to an entity (in the device). That entity is the "user agent" in this context (note that it does not have to represent anything to a user, e.g. in the case of a B2BUA in a SIP system, or to take a less complex example, a GSM telematics module, which is very useful to query and communicate with, but does not have a user interface as such). So when you are addressing data to something using a protocol, the receiver would be the user agent, and the only case when it could not be known is when you are transmitting the information without a prior association (i.e. a broadcast - in all other cases, the data has to be preceeded either by a query or by an invitation). Perhaps we are being misled by an implicit assumption that there is only one user agent per protocol stack. 

Then of course, the user agent and the device can change _during_  the course of the interaction, but that is another (even more interesting) discussion. 

My 2 cents, and apologies if I reiterate the obvious. 

//Johan
________________________________

From:Jo Rabin
Sent: Wednesday, February 28, 2007 6:15 AM
Subject: RE: Device Description definition

This issue came up while we were doing the Best Practices, as follows:

The Device includes the User Agent, but there is no term that describes the aspects of the device that are independent of the user agent.

It seems clear to me that the 'device-as-a-whole' is what we mean to use when using the capabilities in pursuit of e.g. 'exploit device capabilities' but when storing and managing them we should usefully distinguish inherent properties of the "hardware" (or "platform" if you include OS versioning etc.), as opposed to properties of the user agent.

I think fwiw that a single property should be referred to as a device property, or characteristic (possibly) or capability (possibly). But when we say device description we should mean the composite properties of the device and the user agent in question. If the user agent is not known, then, um, er ...

Jo

Received on Wednesday, 28 February 2007 12:05:52 UTC