- From: Lorrie Cranor <lorrie@cs.cmu.edu>
- Date: Wed, 13 Jul 2005 12:10:55 -0400
- To: 'public-p3p-spec' <public-p3p-spec@w3.org>
- Cc: Rigo Wenning <rigo@w3.org>, Giles Hogben <giles.hogben@jrc.it>
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 16:11:50 UTC