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

Re: Data Schema Stuff

From: <giles.hogben@jrc.it>
Date: Wed, 13 Jul 2005 15:35:52 +0200
To: Lorrie Cranor <lorrie@cs.cmu.edu>
Cc: "'public-p3p-spec'" <public-p3p-spec@w3.org>, Rigo Wenning <rigo@w3.org>
Message-id: <6c4326e3535.42d534d8@jrc.it>

I don't think there is a problem with the strings as they would still be in the XSD schema as annotations.
There also is no problem in distinguishing the 2 types of elements you mention:
1. Elements which belong to multiple categories are written under multiple categories in the XML file which defines the category-0>element association. But they do NOT appear in the schema.
2. Variable category elements are the only ones which actually appear in the schema under the categories and NOT directly under the root. This means you have to instantiate them under a category (or more than one).

My point is that a policy writer doesn't need that information and so it depends on APPEL being implemented to be useful.
Even the APPEL engine in the agent wouldn't be using it for XML validation, only for knowing how to match up categories and data elements so the XSD syntax is kind of redundant.
I did also consider your point that it's nice to have a one-stop file for all the information needed and I agree. One option would be to put a redundant branch of the XML schema which never gets instantiated by P3P policies but which could be interpreted by the APPEL engine to find out which categories can be used to match. I think this would look a bit odd though...

If you think it would help to discuss on the phone, send me your telno (off the public list) and I'll call.

> 
> In P3P 1.0 the base data schema definition includes all the 
> category 
> information and the human-readable strings, so a user agent is 
> able to 
> read it one file and have all that information. It would be nice 
> if 
> both the categories and strings could be preserved as they are a 
> normative part of the spec, and user agents may use them (for 
> example 
> Privacy Bird gets all of that information from the base data 
> schema 
> file). Also, if someone defines a new data schema with elements 
> not in 
> the base data schema, how will they indicate the categories?
> 
> Another issue, how do you distinguish between elements that belong 
> to 
> multiple categories, and variable-category elements that could 
> belong 
> to any category depending on what is said in the policy?
> 
> Lorrie
> 
> 
> On Jul 12, 2005, at 3:48 PM, giles.hogben@jrc.it wrote:
> 
> > I've thought out more fully how my proposal for categories would 
> work 
> > using XSD, and I have a proposal for further simlification which 
> I'd 
> > like your thoughts on:
> >
> > First note that categories are NOT used in P3P policies except 
> with 
> > dynamic.miscdata and dynamic cookies elements therefore they 
> have no 
> > meaning in a policy schema except for these elements. However 
> the aim 
> > is that rules (e.g. APPEL) agents can use them to match broad 
> groups 
> > of data elements. So what I'm thinking now is that instead of 
> messing 
> > up the schema with the category assignments which are never used 
> by 
> > the policy, we could do as follows:
> >
> > 1. In the XSD schema, have only the categories that are used - 
> so it 
> > would basically look like the tree in B.  below:
> > This would have no problems with backward compatibility 
> whatsoever and 
> > would achieve the desired simplification.
> > The elements would look like:
> > <navigation><dynamic><miscdata/></dynamic></navigation>
> > OR
> > <user><home-info><postal><name/></postal></home-info></user>
> >
> >
> > 2. We add a separate categories XML file which is NOT an XSD 
> schema 
> > but defines which categories an APPEL like system may associate 
> with 
> > which data elements in a policy (**or we could even leave it up 
> to an 
> > APPEL spec to do this instead of us, having just a 
> recommendation and 
> > example in the spec**). Example of what the file would look like 
> in A. 
> > below
> >
> > The key point to note is that the category assignments for non-
> dynamic 
> > elements are only used by APPEL so there is no need for them to 
> be 
> > part of the XSD.
> >
> > One further small comment is that it makes sense to rename the 
> Name 
> > under business to orgname because it has a different 
> substructure. 
> > This is the only example of where an element with the same name 
> cannot 
> > simply be attached by reference so it makes sense to change it.
> >
> > Let me know what you think and if you agree, I'll implement it 
> this 
> > way,
> >
> > Regards
> >
> > Giles
> >
> > **********************************************************
> > A. Category assignment file (NOT an XSD) defines what can be 
> written 
> > in an APPEL like rule to match what data elements - the agent 
> would 
> > take the LEAF of the policy data element (<name/> in the above) 
> and 
> > see which categories it was included in below to see whether it 
> > matched the rule.
> >
> > <navigation>
> > 	<dynamic/>
> > 	<miscdata/>
> > 	<cookies/>
> > 	<uri/>
> > 	<timestamp/>
> > 	<other.httpmethod/>
> > 	<other.bytes/>
> > 	<other.statuscode/>
> > 	<referrer/>
> > 	<clickstream/>
> > 	<clientevents/>
> > </navigation>
> > <uniqueid>
> > 	<business/>
> > 	<user/>
> > 	<thirdparty/>
> > 	<dynamic/>
> > 	<miscdata/>
> > 	<cookies/>
> > 	<id/>
> > 	<password/>
> > 	<key/>
> > 	<format/>
> > 	<login/>
> > 	<cert/>
> > </uniqueid>
> > <online/>
> > 	<home-info/>
> > 	<business-info/>
> > 	<contact-info/>
> > 	<computer/>
> > 	<dynamic/>
> > 	<miscdata/>
> > 	<cookies/>
> > 	<clickstream/>
> > 	<http/>
> > 	<hostname/>
> > 	<fullip/>
> > 	<useragent/>
> > </online>
> > <interactive>
> > 	<dynamic/>
> > 	<miscdata/>
> > 	<cookies/>
> > 	<searchtext/>
> > 	<interactionrecord/>
> > </interactive>
> >
> > Etc...
> >
> > *************************************
> > B. Revised tree structure of XSD data schema
> > **************************************
> >
> > datatype
> > |
> > +navigation
> > |	+dynamic
> > |        	+miscdata
> > |        	+cookies
> > +uniqueid
> > |	+dynamic
> > |        	+miscdata
> > |        	+cookies
> > +demographic
> > |	+dynamic
> > |        	+miscdata
> > |        	+cookies
> > +physical
> > |	+dynamic
> > |        	+miscdata
> > |        	+cookies
> > +online
> > |	+dynamic
> > |        	+miscdata
> > |        	+cookies
> > +computer
> > |	+dynamic
> > |        	+miscdata
> > |        	+cookies
> > +interactive
> > |	+dynamic
> > |        	+miscdata
> > |        	+cookies
> > +dynamic
> > |    +clickstream
> > |    |  +uri
> > |    |  |  +authority
> > |    |  |  +stem
> > |    |  |  +querystring
> > |    |  +timestamp
> > |    |  |  +ymd.year
> > |    |  |  +ymd.month
> > |    |  |  +ymd.day
> > |    |  |  +hms.hour
> > |    |  |  +hms.minute
> > |    |  |  +hms.second
> > |    |  |  +fractionsecond
> > |    |  |  +timezone
> > |    |  +clientip
> > |    |  |  +hostname
> > |    |  |  +partialhostname
> > |    |  |  +fullip
> > |    |  |  +partialip
> > |    |  +other.httpmethod
> > |    |  +other.bytes
> > |    |  +other.statuscode
> > |    +http
> > |    |  +referer
> > |    |  |  +authority
> > |    |  |  +stem
> > |    |  |  +querystring
> > |    |  +useragent
> > |    +clientevents
> > |    +searchtext
> > |    +interactionrecord
> > |
> > +user
> > |  +name
> > |  |  +prefix
> > |  |  +given
> > |  |  +middle
> > |  |  +family
> > |  |  +suffix
> > |  |  +nickname
> > |  +bdate
> > |  |  +ymd.year
> > |  |  +ymd.month
> > |  |  +ymd.day
> > |  |  +hms.hour
> > |  |  +hms.minute
> > |  |  +hms.second
> > |  |  +fractionsecond
> > |  |  +timezone
> > |  +login
> > |  |  +id
> > |  |  +password
> > |  +cert
> > |  |  +key
> > |  |  +format
> > |  +gender
> > |  +jobtitle
> > |  +home-info
> > |  |  +postal
> > |  |  |  +name
> > |  |  |  |  +prefix
> > |  |  |  |  +given
> > |  |  |  |  +middle
> > |  |  |  |  +family
> > |  |  |  |  +suffix
> > |  |  |  |  +nickname
> > |  |  |  +street
> > |  |  |  +city
> > |  |  |  +stateprov
> > |  |  |  +postalcode
> > |  |  |  +organization
> > |  |  |  +country
> > |  |  +telecom
> > |  |  |  +telephone
> > |  |  |  |  +intcode
> > |  |  |  |  +loccode
> > |  |  |  |  +number
> > |  |  |  |  +ext
> > |  |  |  |  +comment
> > |  |  |  +fax
> > |  |  |  |  +intcode
> > |  |  |  |  +loccode
> > |  |  |  |  +number
> > |  |  |  |  +ext
> > |  |  |  |  +comment
> > |  |  |  +mobile
> > |  |  |  |  +intcode
> > |  |  |  |  +loccode
> > |  |  |  |  +number
> > |  |  |  |  +ext
> > |  |  |  |  +comment
> > |  |  |  +pager
> > |  |  |    +intcode
> > |  |  |    +loccode
> > |  |  |    +number
> > |  |  |    +ext
> > |  |  |    +comment
> > |  |  +online
> > |  |    +email
> > |  |    +uri
> > |  +business-info
> > |    +postal
> > |    |  +name
> > |    |  |  +prefix
> > |    |  |  +given
> > |    |  |  +middle
> > |    |  |  +family
> > |    |  |  +suffix
> > |    |  |  +nickname
> > |    |  +street
> > |    |  +city
> > |    |  +stateprov
> > |    |  +postalcode
> > |    |  +organization
> > |    |  +country
> > |    |telecom
> > |    |  +telephone
> > |    |  |  +intcode
> > |    |  |  +loccode
> > |    |  |  +number
> > |    |  |  +ext
> > |    |  |  +comment
> > |    |  +fax
> > |    |  |  +intcode
> > |    |  |  +loccode
> > |    |  |  +number
> > |    |  |  +ext
> > |    |  |  +comment
> > |    |  +mobile
> > |    |  |  +intcode
> > |    |  |  +loccode
> > |    |  |  +number
> > |    |  |  +ext
> > |    |  |  +ext
> > |    |  |  +ext
> > |    |  |  +comment
> > |    |  +pager
> > |    |    +intcode
> > |    |    +loccode
> > |    |    +number
> > |    |    +ext
> > |    |    +comment
> > |    |online
> > |    |  +email
> > |    |  +uri
> > |    +employer
> > |    +department
> > +thirdparty
> > |  +name
> > |  |  +prefix
> > |  |  +given
> > |  |  +middle
> > |  |  +family
> > |  |  +suffix
> > |  |  +nickname
> > |  +bdate
> > |  |  +ymd.year
> > |  |  +ymd.month
> > |  |  +ymd.day
> > |  |  +hms.hour
> > |  |  +hms.minute
> > |  |  +hms.second
> > |  |  +fractionsecond
> > |  |  +timezone
> > |  +login
> > |  |  +id
> > |  |  +password
> > |  +cert
> > |  |  +key
> > |  |  +format
> > |  +gender
> > |  +jobtitle
> > |  +home-info
> > |  |  +postal
> > |  |  |  +name
> > |  |  |  |  +prefix
> > |  |  |  |  +given
> > |  |  |  |  +middle
> > |  |  |  |  +family
> > |  |  |  |  +suffix
> > |  |  |  |  +nickname
> > |  |  |  +street
> > |  |  |  +city
> > |  |  |  +stateprov
> > |  |  |  +postalcode
> > |  |  |  +organization
> > |  |  |  +country
> > |  |  +telecom
> > |  |  |  +telephone
> > |  |  |  |  +intcode
> > |  |  |  |  +loccode
> > |  |  |  |  +number
> > |  |  |  |  +ext
> > |  |  |  |  +comment
> > |  |  |  +fax
> > |  |  |  |  +intcode
> > |  |  |  |  +loccode
> > |  |  |  |  +number
> > |  |  |  |  +ext
> > |  |  |  |  +comment
> > |  |  |  +mobile
> > |  |  |  |  +intcode
> > |  |  |  |  +loccode
> > |  |  |  |  +number
> > |  |  |  |  +ext
> > |  |  |  |  +comment
> > |  |  |  +pager
> > |  |  |    +intcode
> > |  |  |    +loccode
> > |  |  |    +number
> > |  |  |    +ext
> > |  |  |    +comment
> > |  |  +online
> > |  |    ?email
> > |  |    +uri
> > |  +business-info
> > |    +postal
> > |    |  +name
> > |    |  |  +prefix
> > |    |  |  +given
> > |    |  |  +middle
> > |    |  |  +family
> > |    |  |  +suffix
> > |    |  |  +nickname
> > |    |  +street
> > |    |  +city
> > |    |  +stateprov
> > |    |  +postalcode
> > |    |  +organization
> > |    |  +country
> > |    |telecom
> > |    |  +telephone
> > |    |  |  +intcode
> > |    |  |  +loccode
> > |    |  |  +number
> > |    |  |  +ext
> > |    |  |  +comment
> > |    |  +fax
> > |    |  |  +intcode
> > |    |  |  +loccode
> > |    |  |  +number
> > |    |  |  +ext
> > |    |  |  +comment
> > |    |  +mobile
> > |    |  |  +intcode
> > |    |  |  +loccode
> > |    |  |  +number
> > |    |  |  +ext
> > |    |  |  +comment
> > |    |  +pager
> > |    |    +intcode
> > |    |    +loccode
> > |    |    +number
> > |    |    +ext
> > |    |    +comment
> > |    +online
> > |    |  +email
> > |    |  +uri
> > |    +employer
> > |    +department
> > |
> > +business
> >    +orgname
> >    |department
> >    +cert
> >    |  +key
> >    |  +format
> >    +contact-info
> >      +postal
> >      |  +orgname
> >      |  +name
> >      |  +street
> >      |  +city
> >      |  +stateprov
> >      |  +postalcode
> >      |  +organization
> >      |  +country
> >      +telecom
> >        +telephone
> >        |  +intcode
> >        |  +loccode
> >        |  +number
> >        |  +ext
> >        |  +comment
> >        +fax
> >        |  +intcode
> >        |  +loccode
> >        |  +number
> >        |  +ext
> >        |  +comment
> >        +mobile
> >        |  +intcode
> >        |  +loccode
> >        |  +number
> >        |  +ext
> >        |  +comment
> >        +pager
> >        |  +intcode
> >        |  +loccode
> >        |  +number
> >        |  +ext
> >        |  +comment
> >        +online
> >          +email
> >          +uri
> >
> >
> >
> >
> 
> 
> 
Received on Wednesday, 13 July 2005 13:36:01 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Wednesday, 13 July 2005 13:36:01 GMT