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 08:58:08 UTC