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 14:22:02 UTC