Re: Trouble with data schema

It seems a fairly good reason - perhaps my mail wasn't clear. The change would clarify the XSD a lot and make new ones in the same structure much easier to understand.
I'll have to think about when and if I've got time to do it though. I think it would probably not be done before September (if we made the full change).

Banning new categories would be a quick win  though.

----- Original Message -----
From: Lorrie Cranor <lorrie+@cs.cmu.edu>
Date: Thursday, July 7, 2005 5:29 pm
Subject: 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 
> > [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
> >> [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
> >>> [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
> >>>>> [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>
> >>>>>     
> >>>>>     <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:45:08 UTC