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