RE: Data Schema Stuff

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 16:57:14 UTC