Re: Data structure question

Giles,

This is indeed one of the more confusing areas of the spec.
I believe that if you create a new DATA-STRUCT that overrides
the category of the structure it inherits, then you should ignore
any categories in the original structure. Thus, in the vehicle example,
vehicle.built.where.city, vehicle.built.where.postalcode, etc. all
have the category "preference", despite the fact that they are
defined differently in the postal structure in the base data schema.
So, you need to have your APPEL parser recognize that the
category is being overriden in this case, and act accordingly.

Lorrie



> ----- Forwarded message from Giles Hogben <giles@ontv.com> -----
>
> Date: Sat, 28 Apr 2001 03:10:32 -0400 (EDT)
> Message-ID: <033a01c0cf6e$2e29fdf0$35e9fc3e@Banana>
> From: "Giles Hogben" <giles@ontv.com>
> To: <www-p3p-public-comments@w3.org>
> Subject: [Moderator Action] Data structure question
>
> Hi,
>
> I have a question on what appears to be an anomaly in the P3P spec:
>
> According to the example given in the APPEL spec for category only data
element expansion,
> it's implied that only structref references with matching category
attributes or no category attributes can match a structref element.
> The example shows the onlne category which chooses only the uri elements
from the online category. Any subsequent relational matches via the
structref attribute are then only made to nodes which have  an <online/>
grandchild (i.e. structures also in the online category) and this appears to
make sense.
>
> BUT
>
> In the P3P spec, you give the example of a custom schema involving
motorcycles and cars which gives vehicle.built.where a structref of
..base#postal
> and a category of PREFERENCE.
> But none of the base schema postal structures are in the PREFERENCE
category, which means that a parser running according to the rules implied
in the APPEL spec would ignore any of the nodes with postal references:
>
> Am I confused about something or what is the explanation for this?
>
> Thanks
>
> Giles Hogben
>
> ----- End forwarded message -----

Received on Sunday, 29 April 2001 09:04:49 UTC