RE: [API] interface requirements from Repository document

Hi Andrea,

Sorry, I should have been more clear - there is a requirement in the
Repository requirements which seems to fit better in the API document:

This part of [DDR-USE-QUERY]
- "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."

And all of "[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."

So not a change to an API requirement, just a proposal to move it from
Repository to API.

Cheers
Kevin 



-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Andrea Trasatti
Sent: 04 April 2007 18:57
To: public-ddwg@w3.org
Subject: Re: [API] interface requirements from Repository document


Hello,
	I am unclear which requirement would be changed.

I agree with Rotan and his example about the source of data.

Also, in my mind, the implementation could differ depending on the  
actor. For example, an actor could have access to high level  
information such as "accept header", "UAProf", etc, some other Actor  
such as the DDR admin, will have access to information such as  
"Andrea Trasatti tested on April, 1 2007".

I would leave space to implementations as long as we agree that there  
will be some way to know where the data came from. Eventually, if a  
company or developer does not trust the source anymore, they will  
just switch to another provider.

- Andrea


Il giorno 04/apr/07, alle ore 17:16, Smith, Kevin, VF-Group ha scritto:

>
> 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 Thursday, 5 April 2007 08:17:00 UTC