W3C home > Mailing lists > Public > public-ddwg@w3.org > April 2007

RE: [API] interface requirements from Repository document

From: Smith, Kevin, VF-Group <Kevin.Smith@vodafone.com>
Date: Wed, 4 Apr 2007 17:16:36 +0200
Message-ID: <7753CA22B9752F4496FFDAFFF6627A1466B60B@EITO-MBX03.internal.vodafone.com>
To: <public-ddwg@w3.org>

I like your revision, like you suggest I think we need to decide how the
origin contributes to trust and what granularity of origin is needed.
Potentially this could be down to an indivdual, but I would hope that
would not be mandatory. Have other groups had this kind of discussion,
and can we adopt their principles?

Cheers
Kevin

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Rotan Hanrahan
Sent: 04 April 2007 15:40
To: public-ddwg@w3.org
Subject: RE: [API] interface requirements from Repository document


Again, the proposed wording makes assumptions about possible
implementations. There might be others. (But because I can't think of
them right now, doesn't mean they don't or won't exist.) The mention of
versions is unnecessary, because the generic assertion includes the
specific. So, here's a proposed contraction of your proposed change, and
you'll see that it's short and simple:

"The DDR MUST be able to establish, and subsequently convey to
Authorized Actors, information about the origin of property values and
any assertions about their validity."

It still opens questions about the meaning of "origin". For example,
suppose that someone built a DDR front-end to WURFL, and an Authorized
Actor asked about the provenance of the width property for some device,
would it be sufficient to say "WURFL" or would it be necessary to
identify who submitted that data to WURFL? And if the submitter is a
company, would it be necessary to identify the employee? And should I
also know where that employee got her information...?

To me, I think the granularity of the answer should be only sufficient
to enable me to determine if I should trust the source. In fact, it
might be enough just to know how the data came to be in the DDR, not the
whole chain of origin.

---Rotan


-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Smith, Kevin, VF-Group
Sent: 04 April 2007 15:21
To: public-ddwg@w3.org
Subject: RE: [API] interface requirements from Repository document


In the case of restricted submission, though, could it not be the case
that the trusted provider has got their data from elsewhere? For example
they may trust a manufacturer's UAProf, or a 3rd party test agency, and
simply provision those values to the DDR. In those cases the original
data source would be lost if traceability was simply based on access -
this information may be valuable over and above a 'valid/verified'
confirmation. Maybe I can rephrase the requirement to reflect both
methodologies. Something like:

Current text:
The DDR MUST store the originating source of each property value and any
assertions as to its validity, and allow authorized Actors access to
this information. The same applies to any subsequent versions of the
property value.

Proposed change:
The DDR MUST establish the source of each property value and any
assertions as to its validity, via access controls or explicit metadata.
Authorized Actors MUST be allowed access to this information. The same
applies to any subsequent versions of the property value.

Cheers,
Kevin





-----Original Message-----
From: Rotan Hanrahan [mailto:rotan.hanrahan@mobileaware.com] 
Sent: 04 April 2007 15:06
To: Smith, Kevin, VF-Group; public-ddwg@w3.org
Subject: RE: [API] interface requirements from Repository document

> ....although for this last requirement there will be a Repository
requirement for the data model to include the source and any quality
assertions for a given property.

Not necessarily. Be careful of drifting into assumptions about the
implementation methodology. For example, a DDR may impose its own
restrictions on who has access to the "submit" methods, such that only
trusted providers who give guarantees about validity and verification
can populate the repository. In this case, this particular instance of a
DDR compliant service would have a mechanism that would tell all Actors
that the data is valid and verified, without the data model actually
storing such information. It is simply an implication of the way this
particular DDR operates.

Where possible, we should avoid making any assumptions about how the DDR
could be implemented, and concentrate only on the functional aspects of
the interface itself.

---Rotan

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Smith, Kevin, VF-Group
Sent: 04 April 2007 14:50
To: public-ddwg@w3.org
Subject: [API] interface requirements from Repository document


HI all,

There are requirements in the Repository document pertaining to
interfaces, it makes sense to me to have these reference the API
document, i.e.

[DDR-USE-QUERY]
"It MUST be possible for an authorised consumer to query the DDR to
retrieve a device description, {*} as detailed in the
DeviceDescriptionRepositoryApi requirements ."


The following parts seem to belong in the API document as high-level
requirements, rather than in the Repository document:

- "It MUST be possible for the consumer to define the scope of this
description, namely the device property value or values which he wishes
to retrieve."

- "[DDR-USE-QUALITY-VERIFICATION]
   The DDR MUST support a mechanism to allow an Actor to determine that
the existing, new or modified device description information has been
verified and validated."

....although for this last requirement there will be a Repository
requirement for the data model to include the source and any quality
assertions for a given property.

Cheers
Kevin
Received on Wednesday, 4 April 2007 15:17:10 GMT

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