The statement you refer to in Martin's message is not
part of the specification. It was an explanation for why
another change was made. None the less,
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?
Lorrie
----- 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
>
>