- From: Johan Hjelm \(TO/NRJ\) <johan.hjelm@ericsson.com>
- Date: Wed, 28 Feb 2007 02:41:33 +0100
- To: <public-ddwg@w3.org>
IMHO, it is the compound instance of the [{packaged hardware} and {installed software}] which is being used to request or receive the current instance of the data, which should be the object of the description. This means an implicit hierarchy, since there are (at a guess) fewer ways of combining hardware than software, so it makes sense to take those first. Especially if certain instances of combinations can be given an identifier (e.g. a model name). If the mechanism is generic and can handle the concievable permutations, I see no reason why we should actually do so - just let whomever is putting up the description be responsible for the named instance, and never mind if the bundle of [{intel processor} and {seagate hard disk} and {samsung RAM} and {sharp LCD] is an hp, a lenovo, or whatever. The important thing is to be able to represent the adequate granularity and the relevant parameters, and enable the unambigous naming of this combination (the fact that there may not be any distinguishng factors except the design of the box, well, that is another matter). I also want to re-make the point about user agent and software that I made just before: I am not sure how the user agent could not be known. The data which has to be adapted is either requested by an entity (in the device) and sent in response to a request, or pushed to an entity (in the device) as a result of a previous session setup. 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 > -----Original Message----- > From: public-ddwg-request@w3.org > [mailto:public-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan > Sent: Wednesday, February 28, 2007 6:36 AM > To: public-ddwg@w3.org > Subject: Device Description definition > > > [Moving this to the public list because it is a technical issue.] > > I have a preference for the second alternative definition of > "Device Description" proposed by Kevin (see below), because > it implies a plurality of information. However, there are > still a few technical concerns (and I apologise for seeming > overly pedantic but when it comes to formality, attention to > detail is important). > > - The "description" is not the enumeration itself, it is what > is being enumerated. The description may comprise many parts. > Collectively they may have some structure, and while it is > likely possible to enumerate these parts, it is not a > certainty that the enumeration will be unique. > > - The preposition "of" appears three times. This could cause > confusion. > > - A capability is a property insofar as being an ability to > perform, consume, use or otherwise take an action. So do we > need to say "properties and capabilities" when "properties" > will suffice? > > - The phrase "parameters that define the properties" raises > some questions. A "definition of a property" is something > that captures the semantics associated with a property. For > example, a property called "Physical Width" can have a > definition that says "the maximum distance in meters between > the horizontal extremities of the visible region of the > display when viewed in its default orientation". I doubt we > would think of this as a "parameter". I suspect we would > probably think of "0.0025m" as a parameter. In other words, > the value associated with the property. > > - Regarding "generic instance of a specific device", I > understand the intent, but the word "specific" is not > sufficiently defined, and "generic" opens too many doors. > Instead, I'm thinking more in the line of sets and set > membership based on common properties. The descriptions would > then capture the values of those common properties. This is a > concept that would be less ambiguous than the use of > specific/generic. Since we don't know how restrictive we may > (or should) make the idea of a "specific" device, we might > find it sufficient to refer to a set of devices. That leaves > open the idea of defining the set, which is an issue that > Jose is likely to encounter as he considers our Structures > deliverable. > > OK, enough. You can see why I apologised in advance for my pedantry. > > So, do I have an alternative that fits with the spirit of the > original text? Let's try this: > > === Device description - a collection of attribute-value > pairs that apply to each member of a set of devices. === > > Now, we still have the issue of the definition of Device. As > we all know, the issue of the physical/software duality of > the client were raised during the workshop. We have no clear > idea at this point in time how we should uniquely identify > the client. Many physical units can support the same browser > software, and many browsers can work on multiple hardware > platforms. When a server receives a request, should we > consider this a request from the physical device, the > software device, or some hybrid? And is this hybrid > identified in the request? Can we disambiguate? Can we avoid > the combinatorial explosion that will result from the problem > of identifying hybrids uniquely? > > And finally, note that in the DI Glossary definition we find > the word "apparatus", which some might assume means a > physical entity, but of course an apparatus could equally be > purely software or a combination. I believe this is why that > particular word was used. > > ---Rotan. > > > > From: member-ddwg On Behalf Of Smith, Kevin, VF-Group > Sent: 27 February 2007 17:41 > To: member-ddwg > Subject: Device Description definition > > Hi all, > > As mentioned, here's my first attempt at a definition of > 'Device description' for the DI glossary. Once it is agreed I > can submit it to Rhys and we can refer to it from our documents. > > Device description - a parameter that describes a single > property and/or single capability of a generic instance of a > specific device [1]. > > or > > Device description - an enumeration of the parameters that > define the properties and capabilities of a generic instance > of a specific device . > > ...the difference being that for the former, we imply a > single descriptive item; for the latter, the collective > description of a device's capabilities. > > Notes: > - as the architecture evolves it may be that the definition > changes to mention syntax or datatype (e.g. 'parameter' may > change to 'attribute-value pair' or 'RDF-triple', etc.) > - the definition does not constrain the description to static > properties only, should it? > > Cheers, > Kevin > > > [1] Device is defined in the glossary as "An apparatus > through which a user can perceive and interact with the Web" > (http://www.w3.org/TR/di-gloss/#def-device) > > Kevin Smith > Technology Strategist > Vodafone Research & Development > > [...] > >
Received on Wednesday, 28 February 2007 01:52:13 UTC