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

Lorrie Cranor wrote:

> 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.

Thanks for the quick reply!

I know the paragraph you have mentioned. I might be wrong, but
if I am, I would like to know where I have been mislead.

Let me refer to the following extract from Martin Presler-Marshall's
last message to the mailing list:

: 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.

Now I apply this to the vehicle example:

In P3P, categories must always "bubble upwards" in dataschemas.
Since a policy which declares collecting structured element
"car.built.where"
implicitly includes all subelements
("car.built.where.city", e.g.), 
all categories assigned to any of the sub-elements 
(f.e. the <physical> category, which is assigned to
"car.built.where.city" by the <DATA-STRUCT name="postal.city">)
must be assigned to their parent element
(that is, the <physical> category must be assigned to parent
element of "car.built.where.city", which is "car.built.where"; 
so the <physical> category must be assigned to
"vehicle.built.where").

Am I missing something?

Best regards,
Nikolaj




> ----- 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 11:59:25 UTC