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

Re: Data Schema Stuff

From: Lorrie Cranor <lorrie@cs.cmu.edu>
Date: Wed, 13 Jul 2005 13:08:01 -0400
Message-Id: <649bbe15aa70df925e903b421677f8ee@cs.cmu.edu>
Cc: 'Rigo Wenning' <rigo@w3.org>, Giles Hogben <giles.hogben@jrc.it>
To: 'public-p3p-spec' <public-p3p-spec@w3.org>

Using appinfo looks like a very nice solution!

I don't know the syntax well enough to understand what the choice  
element is doing and the implications of removing it.

Lorrie


On Jul 13, 2005, at 12:57 PM, Giles Hogben wrote:

>
> Removing the categories element still requires the choice element in  
> the xsd
> - to say "at this point you can either have a further data element or a
> category but not both." This is still a major simplification - BUT now  
> I
> think I've got the perfect solution! I looked at the annotation  
> element,
> which I discovered contains the appinfo element, which seems like it  
> might
> be just what we are looking for it's defined as follows:
>
> "The appInfo element specifies information to be used by the  
> application.
> This element must go within an annotation element."
> It can contain XML elements:
> Isn't that exactly what we want?
>
> We could have something like:
>
> <xsd:element name="categoryfoo"/>
> ....
>
> <xsd:element name="cert">
>     <xsd:annotation>
> 	<xsd:appinfo>
> 		<categories  xmlns="http://...p3p">
> 			<uniqueid/>
> 			<foo/>
> 		</categories>
> 	</xsd:appinfo>
>       <xsd:documentation>
>         User's Identity Certificate
>       </xsd:documentation>
>     </xsd:annotation>
>     <xsd:complexType>
>       <xsd:choice>
>           <xsd:element minOccurs="0" maxOccurs="1" ref="key"/>
>           <xsd:element minOccurs="0" maxOccurs="1" ref="format">
>       </xsd:choice>
>     </xsd:complexType>
>  </xsd:element>
>
>
> Another question is if we want to allow for more compact expression of
> multiple types by removing the choice here so you can write:
>
> <datatype><user><online><cert><key/><format/></cert></online></user></ 
> dataty
> pe>
>
>
>
>> **-----Original Message-----
>> **From: public-p3p-spec-request@w3.org
>> **[mailto:public-p3p-spec-request@w3.org] On Behalf Of Lorrie Cranor
>> **Sent: 13 July 2005 18:11
>> **To: 'public-p3p-spec'
>> **Cc: Rigo Wenning; Giles Hogben
>> **Subject: Re: Data Schema Stuff
>> **
>> **
>> **
>> **Giles, Rigo, and I discussed further on the phone.
>> **
>> **My main concern is that I would like the semantics of the base data
>> **schema to be carried with the base data schema, as is done in P3P1.0
>> **and in the proposal in
>> **http://www.w3.org/TR/2005/WD-P3P11-20050701/. As
>> **more things get semantic webized, this will be particularly
>> **important.
>> **
>> **Giles wants to make sure that we can facilitate automatic syntax
>> **validation and that we make it easy for people to create new data
>> **schemas for P3P. The category information is not needed for
>> **validation
>> **and it makes the syntax messy.
>> **
>> **My view is that as long as people use editors rather than
>> **hand coding,
>> **messy syntax is not too much of a concern (within reason). I think
>> **switching to XML schemas is a good thing if we can do it in
>> **a way that
>> **we don't loose anything we had with the P3P1.0 syntax and we can
>> **maintain reasonable backwards compatibility. The transforms
>> **solve the
>> **backwards compatibility problem, and the messy XSD syntax solves the
>> **not losing anything problem. The downside is messy syntax. Is this
>> **messy syntax an improvement on the syntax in P3P1.0?
>> **
>> **We discussed whether there are any syntax alternatives that
>> **would allow
>> **us to keep the semantics in the schema file without messy
>> **syntax. One
>> **possibility is to put categories in an <xsd:documentation> element.
>> **Another possibility is to get rid of the CATEGORIES element and just
>> **keep the child category elements with ref=category. Giles is
>> **going to
>> **ponder the latter possibility and see if that might work for us.
>> **
>> **Another minor issue we discussed was that there should be 17 rather
>> **than 7 categories listed. Only 7 are explicitly used in the BDS, but
>> **the other ten are necessary for the variable-category data elements.
>> **
>> **Lorrie
>> **
>> **On Jul 13, 2005, at 9:35 AM, giles.hogben@jrc.it wrote:
>> **
>> **>
>> **> 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 17:08:57 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Wednesday, 13 July 2005 17:08:58 GMT