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

Lorrie Cranor wrote:

> in this case the bubble upward
> rule still applies however if you keep in mind
> that first you replace the categories for the entire
> data structure with the overriding category givem in
> the example.  Does this make sense now?

Hm. That would mean that, in the example, the

<DATA-STRUCT name="vehicle.built.where"
    structref="http://www.w3.org/TR/P3P/base#postal">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>

assigns the <preferences/> category (and no other category)
to any "vehicle.built.where.foo.bar", so
"vehicle.built.where.city" is in the vehicle category and in
no other.

Now let me apply this to the "dynamic.clickstream"
data element from the P3P base data schema.
As it's defined like this

<DATA-DEF name="dynamic.clickstream"
    structref="#loginfo">
    <CATEGORIES><navigation/><computer/></CATEGORIES>
</DATA-DEF>

, analogously to the example above,
exactly the
<navigation/> and <computer/> categories are assigned
to any "dynamic.clickstream.foo.bar" data element.

So it is/would be impossible to differentiate, and
have only the <demographic/> category assigned to
"dynamic.clickstream.clientip.partialhostname",
*and* only the <computer/> category assigned to
"dynamic.clickstream.clientip.fullip".

Am I wrong?

Nikolaj



> ----- Original Message -----
> From: "Nikolaj Budzyn" <budzyn@ti.informatik.uni-kiel.de>
> To: "Lorrie Cranor" <lorrie@research.att.com>; <www-p3p-policy@w3.org>;
> <www-p3p-dev@w3.org>
> Sent: Thursday, July 12, 2001 12:01 PM
> Subject: 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 17:59:55 UTC