W3C home > Mailing lists > Public > public-p3p-spec@w3.org > July 2005

Re: Trouble with data schema

From: Rigo Wenning <rigo@w3.org>
Date: Wed, 6 Jul 2005 18:39:39 +0200
To: "'public-p3p-spec'" <public-p3p-spec@w3.org>
Message-Id: <200507061839.40522.rigo@w3.org>
Awaiting a better config of the mailing list, I forward those messages 
from Lorrie

----------  [fwd]  ----------

Subject: [Moderator Action] Re: Trouble with data schema
Date: Wednesday 06 July 2005 16:32
From: Lorrie Cranor <lorrie@cs.cmu.edu>
To: Giles Hogben <giles.hogben@jrc.it>
Cc: 'Rigo Wenning' <rigo@w3.org>, public-p3p-spec@w3.org

I don't fully follow what you are proposing... but I am strongly
opposed to any changes that open up nasty new cans of worms at this
point in time.


On Jul 6, 2005, at 6:03 AM, Giles Hogben wrote:
> Hmmmm - I didn't mean that you can't keep using the old categories. I
> just
> mean to simplify the syntax, let's forbid them in future. The point
> is that
> in any new schema, broad categories could simply be expressed as e.g.
> :
> <navigation><cookie/></navigation>
> OR
> <demographic><vehicle><color/></vehicle></demographic>
> One possibility would be to offer them as elements in the new XSD BDS
> so
> that the weird syntax string based ones disappear completely in new
> schemas
> and you just use the element to hook new data elements onto.
> We could even turn the XSD schema up on its head and get rid of the
> string
> based categories so that the XSD defines the categories as elements
> with the
> category would then be at the top level in the data element and
> details would be hooked on below.
> E.g.
> <navigation><cookie/></navigation>
> You could also write them without categories unless they were dynamic
> <user><online><uri/></online></user></navigation>
> Agents would match elements like <navigation/> to all the allowed
> subelements of <navigation>
> This would mean quite a lot of rewriting the transforms etc... I
> estimate 2
> weeks extra work. It may also have nasty implications for APPEL. Any
> thoughts.
> -----Original Message-----
> From: public-p3p-spec-request@w3.org
> [mailto:public-p3p-spec-request@w3.org]
> On Behalf Of Rigo Wenning
> Sent: Wednesday, July 06, 2005 11:28
> To: Giles Hogben
> Cc: 'Lorrie Cranor'; public-p3p-spec@w3.org
> Subject: Re: Trouble with data schema
> Am Wednesday 06 July 2005 09:27 verlautbarte Giles Hogben :
>> I would like to propose a simplification which there is still time
>> to put in the spec. We include categories in the Base Data Schema
>> for backward compatibility - but we disallow them in custom schemas
>> from now on.
> I don't get you here. One of the features of the category system was,
> that new custom data elements could be attached to the existing broad
> categories thus giving the custom elements some meaning. This meaning
> would then be easier to understand for user agents.
> ***There is nothing to stop you doing that.
>> If you want to put in broad categories, there's nothing stopping you
>> - you just have to make them into data elements which subsume the
>> narrower categories. There's no need for a completely different and
>> confusing syntax.
> Can you give an example how this would look like?
>> Yes it's because of XSD. Basically because each
>> data element takes a subset of categories from a global set, this is
>> only possible with a custom data type (or at least that's the only
>> way we could find to do it and we consulted some XML lists)...
> Can we say that we don't allow for NEW categories? Because in your
> example in the Spec, you say:
> <element minoccurs="0" maxoccurs="1" name="musical-preference">
>   <element minoccurs="0" maxoccurs="1"
> ref="classicalmusic-preference"/>
>     <annotation>
>       <documentation>
>         Musical Preferences
>       </documentation>
>     </annotation>
>     <element ref="CATEGORY" minoccurs="0" maxoccurs="*"
>              type="allCategories"/>
>   </element>
> So if you wanted new <category> - Elements, you would have to make
> them available in a custom XML Schema? How would that fit in our
> framework?
> Best,
> Rigo


Received on Wednesday, 6 July 2005 16:39:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:19 UTC