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

RE: Trouble with data schema

From: Giles Hogben <giles.hogben@jrc.it>
Date: Wed, 06 Jul 2005 16:38:02 +0200
To: "'Lorrie Cranor'" <lorrie@cs.cmu.edu>
Cc: "'Rigo Wenning'" <rigo@w3.org>, public-p3p-spec@w3.org
Message-id: <000601c58238$505d04e0$5f2abf8b@cs.jrc.it>

I think disallowing categories in new data schemas does not open up a can of
worms. It probably closes up a few.
Changing the XSD we already have does... (and would be quite a lot of work).

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 14:38:38 UTC

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