Re: Trouble with data schema

Hmm... so that doesn't sounds like there is a really good reason to 
make the change. Yet most of the downsides are more work for you Giles. 
So do you still think it is worth doing?

Lorrie


On Jul 7, 2005, at 8:26 AM, Giles Hogben wrote:

> Yes that's right most of the work for me.
> Other downsides - it's harder to understand what it all means - if we 
> make
> the change, there's only one way of creating a category in both the 
> BDS and
> custom schemas - not 2 ways with one of them being a weird one 
> involving
> custom XSD data types.
> As most policies will be done with an editor I'm not sure shorter or 
> longer
> policies (within reason) is an important consideration - I suppose it's
> quite important for uptake that XML policies are easily readable 
> because in
> the end implementers like to delve into the XML to have a look what's 
> going
> on.
>
> -----Original Message-----
> From: public-p3p-spec-request@w3.org 
> [mailto:public-p3p-spec-request@w3.org]
> On Behalf Of Lorrie Cranor
> Sent: Thursday, July 07, 2005 13:57
> To: 'public-p3p-spec'; Giles Hogben
> Cc: 'Rigo Wenning'
> Subject: Re: Trouble with data schema
>
>
>
>
> On Jul 7, 2005, at 7:48 AM, Giles Hogben wrote:
>
>> I don't understand this sentence: "But I
>> think reving to a new version of the data schema in the case that
>> there was consensus for a new category makes sense."
>>
>
> What I meant was that if there was ever in the future a consensus that
> P3P needed a new data category, I think it would make sense to issue a
> new version that included that category.
>
>> There would be work in changing the p3p1.0 BDS -> p3p1.1 BDS transform
>> and
>> the 2 policy transforms (forwards and backwards), and the work that's
>> been
>> done on our policy editor would need changing somewhat.
>
> So, most of the work is work for you Giles... any other implications?
>
> If we don't make the change is there any downside other than longer
> policies?
>
> Lorrie
>
>
>>
>> -----Original Message-----
>> From: public-p3p-spec-request@w3.org
>> [mailto:public-p3p-spec-request@w3.org]
>> On Behalf Of Lorrie Cranor
>> Sent: Thursday, July 07, 2005 13:41
>> To: Giles Hogben
>> Cc: 'Rigo Wenning'; 'public-p3p-spec'
>> Subject: Re: Trouble with data schema
>>
>>
>>
>> Ah, ok, I understand now. I think saying we cannot create new
>> categories is a reasonable limitation for P3P 1.1. Nobody has ever
>> done this or expressed interest in doing this, although I understand
>> theoretically why someone might want to do it in the future. But I
>> think reving to a new version of the data schema in the case that
>> there was consensus for a new category makes sense.
>>
>> As for the question of whether category names are elements or not....
>> is there a downside to making category names an element other than
>> having to change the transforms?
>>
>> As far as impact on APPEL, as long as the old format is included in
>> the policies, APPEL can continue to use that if need be. At some point
>> APPEL needs overhaul, and then it would make sense to switch to
>> evaluating the new format, so then I think it could be made to work
>> with either elements or not, so I don't think that's a worry.
>>
>> Lorrie
>>
>>
>> On Jul 7, 2005, at 3:57 AM, Giles Hogben wrote:
>>
>>>
>>> The change I'm suggesting is that we say new schemas cannot create
>>> new categories, they can only refer to categories from the base data
>>> schema. That is they can say that their elements are in categories
>>> but they can't make new categories and put the elements into them.
>>>
>>> It would be even better, given time, to convert the BDS categories
>>> (which are currently expressed as string values of CATEGORY tags, for
>>> xsd
>>> reasons)
>>> to data types like all the rest, but standing at the top of the
>>> hierarchy (as they are semantically speaking). That means that
>>> elements using categories would then look like
>>> <demographic><dynamic><cookie/></dynamic></demographic> instead of
>>> <dynamic><cookie><CATEGORY>demographic</CATEGORY></cookie></dynamic> 
>>> -
>>> but
>>> this would change the transforms and as you say open up a can of
>>> worms.
>>>
>>>
>>> -----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 18:41
>>> To: 'public-p3p-spec'
>>> Subject: 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
>>>
>>> -------------------------------------------------------
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>

Received on Thursday, 7 July 2005 15:30:06 UTC