Re: Trouble with data schema

again, a list problem...

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

Subject: [Moderator Action] Re: Trouble with data schema
Date: Wednesday 06 July 2005 16:48
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 still am not getting what you mean by disallowing categories in new
data schemas. As rigo said, the whole point of categories was so that
user agents would have some clue about new data schemas. I'm not really
sure what change to the current working draft you are proposing.

Lorrie

On Jul 6, 2005, at 10:38 AM, Giles Hogben wrote:
> 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.
>
> Lorrie
>
> 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

-------------------------------------------------------