Re: CfO on Issue 22 - Strong objections to both options ;-(

Hi Mike,


thanks a lot for the feedback and the endorsement.

I actually agree that the compliance field is the better place for what
I intended (sorry: my TPE skills got a bit rusty over the years ;-)


Regards,
matthias


On 18.06.2017 16:00, Mike O'Neill wrote:
> I think the compliance array is a more suitable place. The extensions would naturally fit a European compliance document and the compliance property was designed for that. Also "documented by a document" is a bit circular.
> 
> Otherwise I (reluctantly) agree with the change to process and this consensus text.
> 
> So:
> 
> The tracking status object can be extended by adding additional informational properties or by defining additional tracking status values. 
> We require that extensions introduced SHOULD be defined and described by a document referenced by a URL in the compliance array property.  
> Note: One goal of this extensibility is to enable variations by policy and the evolution of best practices for the emerging EU regulations.
> 
> Mike
> 
> 
> -----Original Message-----
> From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
> Sent: 18 June 2017 11:28
> To: public-tracking@w3.org
> Subject: CfO on Issue 22 - Strong objections to both options ;-(
> 
> Dear TPWG,
> 
> 
> I now took some time to analize both sets of objections.
> 
> Both sides have strong objections:
> - Not inserting additional information means that we may not satisfy the
>   transparency requirements put forward by the EU  and thus puts us as
>   risk of not reaching our chartered goal.
> - Inserting the proposed text may also not be sufficient to reach this
>   goal (there may be more fields and data required such as purpose)
>   furthermore, the meaning of the field seems to be not 100% clear.
> 
> I now believe that it is premature to define the right field or set of
> fields.
> 
> I strongly believe that it is too early to identify the best set of
> fields at this point. I also realized that adding all the right fields
> would make this global standard fairly specific to the EU requirements
> (adding burden to other Geos).
> 
> As a consequence, I decided not to force the issue now and propose a
> compromise:
>   - We push out the standard as is
>   - We make its extensibility more explicit to foster continued
>   discussion of EU best practices (in the spec).
>   - We start documenting those best practices as they evolve
> 
> This allows us to keep our timeline while permitting continued learning
> during implementation.
> 
> The change to the spec that I propose is:
>> The tracking status object can be extended by adding additional 
>> informational properties or by defining additional tracking status values. 
>> We require that extensions introduced SHOULD be defined and documented by 
>> a policy document referenced by the URL in the policy property field.
>> Note: One goal of this extensibility is to enable variations by policy and 
>> the evolution of best practices for the emerging EU regulations.
> 
> If we all agree on this consensus, then I will not resolve the CfO by
> forcing the issue and we can move ahead by introducing this change.
> 
> I am confident that all of you can live with this proposal in the spirit
> of jointly finding the solution with least objections.
> 
> If not, please object and substantiate your objection by June 24.
> 
> I am also open to any other feedback (including minor/editorial changes
> to the text I proposed).
> 
> 
> Regards,
> matthias
> 
> PS: Attached is the draft CfP analysis (without conclusion).
> 
>

Received on Sunday, 18 June 2017 14:54:42 UTC