W3C home > Mailing lists > Public > www-p3p-dev@w3.org > July 2001

Re: Inconsistency in the definition of dynamic.clickstream.clientip and its sub-elements -- category transitivity?

From: Lorrie Cranor <lorrie@research.att.com>
Date: Thu, 12 Jul 2001 09:20:37 -0400
Message-ID: <000901c10ad5$70f15320$9816cf87@barbaloot>
To: "Nikolaj Budzyn" <budzyn@ti.informatik.uni-kiel.de>, <www-p3p-policy@w3.org>, <www-p3p-dev@w3.org>
The example is correct. A <DATA-STRUCT> may redefine
the categories in a structure it references. See the third
paragraph from the end of section 5.1. We have not
made any changes to the spec that impact this.

Regards,

Lorrie Cranor

----- Original Message -----
From: "Nikolaj Budzyn" <budzyn@ti.informatik.uni-kiel.de>
To: <www-p3p-policy@w3.org>; <www-p3p-dev@w3.org>
Sent: Thursday, July 12, 2001 8:52 AM
Subject: Re: Inconsistency in the definition of dynamic.clickstream.clientip
and its sub-elements -- category transitivity?


> Martin Presler-Marshall wrote:
>
> > The last inconsistency regards the categories assigned to
> > dynamic.clickstream.clientip. In P3P, categories must always "bubble
> > upwards" in dataschemas. Since a policy which declares collecting
> > structured element a.b.c implicitly includes all subelements (a.b.c.x,
> > a.b.c.y, a.b.c.z), all categories assigned to any of the sub-elements
must
> > be assigned to their parent element.
>
> This sounds convincing. However, it does not fit into what's said in
> chapter 5.1 of the P3P CR spec. Consider the vehicle example:
>
> <DATA-STRUCT name="vehicle.built.where"
>     structref="http://www.w3.org/TR/P3P/base#postal">
>     <CATEGORIES><preference/></CATEGORIES>
> </DATA-STRUCT>
>
> where postal is defined as
>
> <DATA-STRUCT name="postal.city">
>     <CATEGORIES><physical/></CATEGORIES>
> </DATA-STRUCT>
> etc.
>
> If the statement
>
> > all categories assigned to any of the sub-elements must
> > be assigned to their parent element.
>
> holds, this would mean, that as "postal.city" is assigned
> to the <physical> category, "vehicle.build.where" must
> be assigned to the <physical> category, too.
>
> In general, no sub-element could leave out a category it
> "inherits" (<physical> , e.g.), the sub-element only might
> be allowed to add a category. So it won't be possible to
> "redefine" categories as described in chapter 5.1 of the
> CR spec.
>
> By this, DATA-STRUCTs become significantly less useful,
> I guess: In the given example, if the company wants to make
> use of the "postal" data structure, it would have to declare collecting
> <physical> information, although the company might merely
> collect information about the customers' <preferences>.
> This seems to discourage the use of the data structures
> included in the base data schema significantly.
>
> Nikolaj
>
>
Received on Thursday, 12 July 2001 09:22:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 18 June 2010 00:12:47 GMT