- From: Smith, Kevin, VF-Group <Kevin.Smith@vodafone.com>
- Date: Wed, 4 Apr 2007 16:21:20 +0200
- To: <public-ddwg@w3.org>
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