5 DATA SCHEMAS

A data schema is a description of a set of data. P3P includes a way to describe data schemas so that services can communicate to user agents about the data they collect. A data schema is built from a number of data elements, which are specific items of data a service might collect.

Data elements in a data schema can have the following properties:

• Data element name. The name of the data element is used when a P3P policy includes this data element in a <DATA> element. This is required on all data elements.

• Descriptive name or short name. A data element's short name provides a short, human-understandable name for the data element. The short name is not required, but it is strongly recommended.

• Long description. The long description of a data element provides a more detailed, human-understandable definition of the data element. Like the short name, the long description is not required, but it is strongly recommended.

• Category or categories. Most data elements have categories assigned to them when they are defined in a data schema. See Categories for more information on categories.

Data elements are organized into a hierarchy. A data element automatically includes all of the data elements below it in the hierarchy. For example, the data element representing "the user's name" includes the data elements representing "the user's given name," "the user's family name," and so on. The hierarchy is based on the data element name. Thus the data elements user.name.given, user.name.family, and user.name.nickname are all children of the data element user.name, which is in turn a child of the data element user.

P3P has defined a data schema called the P3P base data schema that includes a large number of data elements commonly used by services.

Services may declare new data elements by creating and publishing their own data schemas. This is done with the <DATASCHEMA> element. These can either be published in standalone XML files, which are then referenced by policies that use them, or they can be embedded in the policies files that reference them. The <DATASCHEMA> element is defined as follows:

"<DATASCHEMA" [` xmlns="http://www.w3.org/2001/
09/P3Pv1"`] ">"
*(datadef|datastruct|extension)
"</DATASCHEMA>"

A standalone data schema has the <DATASCHEMA> element as the first XML element in the file. It must have the appropriate namespace defined in the xmlns attribute to identify it as a P3P data schema, as follows:

<DATASCHEMA xmlns="http://www.w3.org/2001/09/P3Pv1">
<DATA-STRUCT ... />
...
<DATA-DEF ... />
</DATASCHEMA>

When a data schema is declared inside a policy file, then the <DATASCHEMA> element is still used (as described in Section 3.2.1, "The <POLICIES> Element"), but no namespace attribute is given.

5.1 Natural Language Support for Data Schemas

Data schemas contain a number of fields in natural language. Services publishing a data schema MAY wish to translate these fields into multiple languages. The data element short and long names MAY be translated, but the data element name MUST NOT be translated?this field needs to stay constant across translations of a data schema.

If a service is going to provide a data schema in multiple natural languages, then it SHOULD examine the Accept-Language HTTP request-header on requests for that data schema to pick the best available alternative.

5.2 Data Structures

Data schemas often need to reuse a common group of data elements. P3P data schemas support this through data structures. A data structure is a named, abstract definition of a group of data elements. When a data element is defined, it can be defined as being of an unstructured type, in which case it has no child elements. The data element can also be defined as being of a specific structured type, in which case the data element will be automatically expanded to include as sub-elements all of the elements defined in the data structure. For example, the following structure is used to represent a date and time:

<!-- "date" Data Structure -->
<DATA-STRUCT name="date.ymd.year"
    short-description="Year"/>

<DATA-STRUCT name="date.ymd.month"
    short-description="Month"/>

<DATA-STRUCT name="date.ymd.day"
    short-description="Day"/>

<DATA-STRUCT name="date.hms.hour"
    short-description="Hour"/>

<DATA-STRUCT name="date.hms.minute"
    short-description="Minute"/>

<DATA-STRUCT name="date.hms.second"
    short-description="Second"/>

Now we shall define a "meeting" data element, which has a time and place for the meeting:

<DATA-DEF name="meeting.time"
    short-description="Meeting time"
    structref="#date"/>
<DATA-DEF name="meeting.place"
    short-description="Meeting place/>

Since meeting.place does not reference a structure, it is of an unstructured type, and has no child elements. The meeting.time element uses the date structure. By declaring this, the following sub-elements are created:

meeting.time.ymd.year
meeting.time.ymd.month
meeting.time.ymd.day
meeting.time.hms.hour
meeting.time.hms.minute
meeting.time.hms.second

A P3P policy can now declare that it collects the meeting data element, which implies that it collects all of the sub-elements of meeting, or it can use data elements lower down the hierarchy?meeting.time, for example, or meeting.time.ymd.day.

5.3 The DATA-DEF and DATA-STRUCT Elements

<DATA-DEF> and <DATA-STRUCT>

Define a data element or a data structure, respectively. Data structures are reusable structured type definitions that can be used to build data elements. Data elements are declared within a <STATEMENT> in a P3P policy to describe data covered by that statement.

The following attributes are common to these two elements:

• name (mandatory attribute)

  Indicates the name of the data element or data structure. Remember that names of data element and data structures are case-sensitive, so, for example, user.gender is different from USER.GENDER or User.Gender. Furthermore, in names of data elements and structures no number character can appear immediately following a dot.

• structref

  URI reference ([URI]), where the fragment identifier part denotes the structure, and the URI part denotes the corresponding data schema where it is defined. The default base URI is a same-document reference ([URI]). Data elements or data structures without a structref attribute (and, so, without an associated structure) are called unstructured.

• short-description

  A string denoting the short display name of the data element or structure, no more than 255 characters.

  The DATA-DEF and DATA-STRUCT elements can also contain a long description of the data element or structure, using the LONG-DESCRIPTION element.

"<DATA-DEF name=" quotedstring
 [` structref="` URI-reference `"`]
 [" short-description=" quotedstring]
 ">"
 [categories] ; the categories of the
                data element.
 [longdescription] ; the long description of
                     the data element
"</DATA-DEF>"

"<DATA-STRUCT name=" quotedstring
 [` structref="` URI-reference `"`]
 [" short-description=" quotedstring]
 ">"
 [categories] ; the categories of the
                Data Structure.
 [longdescription] ; the long description of the
                     Data Structure
"</DATA-STRUCT>"

Data elements can be structured, much like in common programming languages: structures are hierarchical (tree-like) descriptions of data elements: this hierarchical description is performed in the name attribute using a full stop (".") character as separator.

P3P provides the P3P base data schema, which has built-in definitions of a number of widely used structures and data elements. All P3P implementations are required to understand the P3P base data schema, so the structures and elements it defines are always available to P3P implementers.

5.3.1 Categories in P3P Data Schemas

Categories can be assigned to data structures or data elements. The following rules define how those category definitions are meant to be used:

5.3.2 P3P Data Schema Example

Consider the case where the company HyperSpeedExample wishes to describe the features of a vehicle, using a structure called vehicle. This structure includes:

• The vehicle's model type (vehicle.model),

• The vehicle's color (vehicle.color),

• The vehicle's year of manufacture (vehicle.built.year), and

• The vehicle's price (vehicle.price).

If HyperSpeedExample also wants to include in the definition of a vehicle the location of manufacture, it could add other fields to the structure with all the relevant data like country, street address, postal code, and so on. But, each part of a structure can use other structures as well: structures can be composed. In this case, the P3P base data schema already provides a structure postal, describing all the postal information of a location. So, the final definition of the structure vehicle is

• vehicle.model (unstructured)

• vehicle.color (unstructured)

• vehicle.price (unstructured)

• vehicle.built.year (unstructured)

• vehicle.built.where (with structure postal from the base data schema)

The structure postal has fields postal.street, postal.city, and so on. Since we have applied the structure postal to vehicle.built.where, it means that we can access the street and city of a vehicle using the descriptions vehicle.built.where.street and vehicle.built.where.city respectively. So, by applying a structure (in this case, postal) we can build very complex descriptions in a modular way.

HyperSpeedExample wants to declare that all of the vehicle information will be in the <preference/> category. The vehicle.model, vehicle.color, vehicle.price, and vehicle.built.year fields are all unstructured types, so assigning them to the <preference/> category accomplishes this for those fields. Since vehicle is a structure definition, assigning the <preference/> category to vehicle.built.where will override (replace) the categories defined on all of the sub-elements of vehicle.built.where, placing all of them in the <preference/> category, even though the postal structure was originally defined as being in other categories.

As said, structures do not contain data elements; they are just abstract data types. We can use them to rapidly build structured collections of data elements. Going on with the example, HyperSpeedExample needs this abstract description of the features of a vehicle because it wants to actually exchange data about cars and motorcycles. So, it could define two data elements called car and motorcycle, both with the above structure vehicle.

This description of the data elements and data structures is encoded in XML using a data schema. In the HyperSpeedExample case, it would be something like:

<DATASCHEMA xmlns="http://www.w3.org/2001/09/P3Pv1">
<DATA-STRUCT name="vehicle.model"
    short-description="Model">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.color"
    short-description="Color">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.built.year"
    short-description="Construction Year">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.built.where"
    structref="http://www.w3.org/TR/P3P/base#postal"
    short-description="Construction Place">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-DEF name="car" structref="#vehicle"/>
<DATA-DEF name="motorcycle" structref="#vehicle"/>
</DATASCHEMA>

Continuing with the example, in order to reference a car model and construction year, Hyperspeed or any other service could send the following references inside a P3P policy:

<DATA-GROUP>
  <!-- First, the "car.model" data element, whose definition is in
   the data schema at http://www.HyperSpeed.example.com/models-schema
   -->
<DATA ref="http://www.HyperSpeed.example.com/models-schema#car.model"/>
  <!-- And second, the "car.built.year" data element, whose definition
   is the data schema at http://www.HyperSpeed.example.com/
   models-schema
   -->
<DATA ref="http://www.HyperSpeed.example.com/
   models-schema#car.built.year"/>
</DATA-GROUP>

Using the base attribute, the above references can be written in an even more compact way:

<DATA-GROUP base="http://www.HyperSpeed.example.com/models-schema">
    <DATA ref="#car.model"/>
    <DATA ref="#car.built.year"/>
</DATA-GROUP>

Alternatively, the data schema could be embedded directly into a policy file. In this case, the policy file could look like:

<POLICIES xmlns="http://www.w3.org/2001/09/P3Pv1">
<!-- Embedded data schema -->
<DATASCHEMA>
<DATA-STRUCT name="vehicle.model"
    short-description="Model">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.color"
    short-description="Color">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.built.year"
    short-description="Construction Year"">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.built.where"
    structref="http://www.w3.org/TR/P3P/base#postal"
    short-description="Construction Place">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-DEF name="car" structref="#vehicle"/>
<DATA-DEF name="motorcycle" structref="#vehicle"/>
</DATASCHEMA>
<!-- end of embedded data schema -->
<POLICY name="policy1" discuri="http://www.example.com/disc1">
...
<DATA-GROUP base="">
<DATA ref="#car.model"/>
<DATA ref="#car.built.year"/>
</DATA-GROUP>
...
</POLICY>
<POLICY name="policy2" discuri="http://www.example.com/disc2"> .... </
POLICY>
<POLICY name="policy3" discuri="http://www.example.com/disc3"> .... </
POLICY>
</POLICIES>

Note that in any case there MUST NOT be more than one data schema per file.

5.3.3 Use of Data Element Names

Note that the data element names specified in the base data schema or in extension data schemas may be used for purposes other than P3P policies. For example, Web sites may use these names to label HTML form fields. By referring to data the same way in P3P policies and forms, automated form-filling tools can be better integrated with P3P user agents.

5.4 Persistence of Data Schemas

An essential requirement on data schemas is the persistence of data schemas: data schemas that can be fetched at a certain URI can only be changed by extending the data schema in a backward-compatible way (that is to say, changing the data schema does not change the meaning of any policy using that schema). This way, the URI of a policy acts in a sense like a unique identifier for the data elements and structures contained therein: any data schema that is not backward-compatible must therefore use a new different URI.

Note that a useful application of the persistence of data schema is given for example in the case of multi-lingual sites: multiple language versions (translations) of the same data schema can be offered by the server, using the HTTP "Content-Language" response header field to properly indicate that a particular language has been used for the data schema.

5.5 Basic Data Structures

The Basic Data Structures are structures used by the P3P base data schema (and possibly, due to their basic nature, they should be reused as much as possible by other different data schemas). All P3P-compliant user agent implementations MUST be aware of the Basic Data Structures. Each table below specifies the elements of a basic data structure, the categories associated, their structures, and the display names shown to users. More than one category may be associated with a fixed data element. However, each base data element is assigned to only one category whenever possible. Data schema designers are recommended to do the same.

5.5.1 Dates

The date structure specifies a date. Since date information can be used in different ways, depending on the context, all date information is tagged as being of "variable" category (see Section 5.7.2). For example, schema definitions can explicitly set the corresponding category in the element referencing this data structure, where soliciting the birthday of a user might be "Demographic and Socioeconomic Data," while the expiration date of a credit card might belong to the "Purchase Information" category.

The "time zone" information is for example described in the time standard [ISO8601]. Note that "date.ymd" and "date.hms" can be used to fast reference the year/month/day and hour/minutes/seconds blocks respectively.

5.5.2 Names

The personname structure specifies information about the naming of a person.

5.5.3 Logins

The login structure specifies information (IDs and passwords) for computer systems and Web sites which require authentication. Note that this data element should not be used for computer systems or Web sites which use digital certificates for authentication: in those cases, the certificate structure should be used.

The "id" field represents the ID portion of the login information for a computer system. Often, user IDs are made public, while passwords are kept secret. This does not include any type of biometric authentication mechanisms.

The "password" field represents the password portion of the login information for a computer system. This is a secret data value, usually a character string, that is used in authenticating a user. Passwords are typically kept secret, and are generally considered to be sensitive information

5.5.4 Certificates

The certificate structure is used to specify identity certificates (like, for example, X.509).

The "format" field is used to represent the information of an IANA registered public key or authentication certificate format, while the "key' field is used to represent the corresponding certificate key.

5.5.5 Telephones

The telephonenum structure specifies the characteristics of a telephone number.

5.5.6 Contact Information

The contact structure is used to specify contact information. Services can specify precisely which set of data they need, postal, telecommunication, or online address information.

5.5.6.1 Postal

The postal structure specifies a postal mailing address.

The "country" field represents the information of the name of the country (for example, one among the countries listed in [ISO3166]).

5.5.6.2 Telecommunication

The telecom structure specifies telecommunication information about a person.

5.5.6.3 Online

The online structure specifies online information about a person.

5.5.7 Access Logs and Internet Addresses

Two structures used for representing forms of Internet addresses are provided. The uri structure covers Universal Resource Identifiers (URI), which are defined in more detail in [URI]. The ipaddr structure represents IP addresses and Domain Name System (DNS) hostnames.

5.5.7.1 URI

The authority of a URI is defined as the authority component in [URI]. The stem of a URI is defined as the information contained in the portion of the URI after the authority and up to (and including) the first "?" character in the URI, and the querystring is the information contained in the portion of the URI after the first "?" character. For URIs which do not contain a "?"character, the stem is the entire URI, and the querystring is empty.

Since URI information can be used in different ways, depending on the context, all the fields in the uri structure are tagged as being of "variable" category. Schema definitions MUST explicitly set the corresponding category in the element referencing this data structure.

5.5.7.2 ipaddr

The ipaddr structure represents the hostname and IP address of a system.

The hostname element is used to represent collection of either the simple hostname of a system, or the full hostname including domain name. The partialhostname element represents the information of a fully-qualified hostname which has had at least the host portion removed from the hostname. In other words, everything up to the first "." in the fully-qualified hostname MUST be removed for an address to qualify as a "partial hostname."

The fullip element represents the information of a full IP version 4 or IP version 6 address. The partialip element represents an IP version 4 address (only?not a version 6 address) which has had at least the last 7 bits of information removed. This removal MUST be done by replacing those bits with a fixed pattern for all visitors (for example, all 0s or all 1s).

Certain Web sites are known to make use not of the visitor's entire IP address or hostname, but rather make use of a reduced form of that information. By collecting only a subset of the address information, the site visitor is given some measure of anonymity. It is certainly not the intent of this specification to claim that these "stripped" IP addresses or hostnames are impossible to associate with an individual user, but rather that it is significantly more difficult to do so. Sites which perform this data reduction MAY wish to declare this practice in order to more-accurately reflect their practices.

5.5.7.3 Access Log Information

The loginfo structure is used to represent information typically stored in Web-server access logs.

The resource in the HTTP request is captured by the uri field. The time at which the server processes the request is represented by the timestamp field. Server implementations are free to define this field as the time the request was received, the time that the server began sending the response, the time that sending the response was complete, or some other convenient representation of the time the request was processed. The IP address of the client system making the request is given by the clientip field.

The other data fields represent other information commonly stored in Web server access logs. other.httpmethod is the HTTP method (such as GET, POST, etc.) in the client's request. other.bytes indicates the number of bytes in the response-body sent by the server. other.statuscode is the HTTP status code on the request, such as 200, 302, or 404 (see section 6.1.1 of [HTTP1.1] for details).

5.5.7.4 Other HTTP Protocol Information

The httpinfo structure represents information carried by the HTTP protocol which is not covered by the loginfo structure.

The useragent field represents the information in the HTTP User-Agent header (which gives information about the type and version of the user's Web browser), and/or the HTTP accept* headers.

The referer field represents the information in the HTTP Referer header, which gives information about the previous page visited by the user. Note that this field is misspelled in exactly the same way as the corresponding HTTP header.

5.6 The Base Data Schema

All P3P-compliant user agent implementations MUST be aware of the data elements in the P3P base data schema. The P3P base data schema includes the definition of the basic data structures, and four data element sets: user, thirdparty, business and dynamic. The user, thirdparty and business sets include elements that users and/or businesses might provide values for, while the dynamic set includes elements that are dynamically generated in the course of a user's browsing session. User agents may support a variety of mechanisms that allow users to provide values for the elements in the user set and store them in a data repository, including mechanisms that support multiple personae. Users may choose not to provide values for these data elements.

The formal XML definition of the P3P base data schema is given in Appendix 3. In the following sections, the base data elements and sets are explained one by one. In the future there will be in all likelihood demand for the creation of other data sets and elements. Obvious applications include catalogue, payment, and agent/system attribute schemas (an extensive set of system elements is provided for example in http://www.w3.org/TR/NOTE-agent-attributes).

Each table below specifies a set, the elements within the set, the category associated with the element, its structure, and the display name shown to users. More than one category may be associated with a fixed data element. However, each base data element is assigned to only one category whenever possible. It is recommended that data schema designers do the same.

5.6.1 User Data

The user data set includes general information about the user.

About Prentice Hall Professional Technical Reference Foreword Preface Who Is This Book For? Acknowledgments Part 1: Introduction Chapter 1. Mobile Location Services The GIS and Wireless Industries Meet Market Drivers New Opportunities and Challenges for Application Developers Chapter 2. Building a Mobile Location Services Solution Wireless and Mobile Network Basics The Mobile Location Services Industry Solution Components: What Makes a Mobile Location Solution? Part 2: The Mobile Location Server Chapter 3. The Application Server What Is an Application Server? Why Is an Application Server Important? J2EE Application Server Endnotes Chapter 4. Spatial Analysis Sample Spatial Analysis Server Digital Maps Geographical Data Types Projections and Coordinate Systems' [1] ' Geocoding Reverse Geocoding Routing Map Image Generation POI Searches Real-Time Attribute Editing Endnotes Chapter 5. Mobile Positioning Cell of Origin GPS Enhanced-Observed Time Difference Angle of Arrival Time Difference of Arrival Location Pattern Matching Map Matching Positioning Accuracy and Speed Requirements for Mobile Location Services Applications Chapter 6. Authentication and Security Special Concerns In Wireless Networks Endnotes Chapter 7. Personalization and Profiling What Is Personalization and Why Is It Important? A Personalization and Profiling System Privacy Issues Endnotes Chapter 8. Billing Technology and Business Models Roaming Who Will Pay? Chapter 9. Mobile Commerce What Is M-Commerce? Mobile Electronic Transactions Standard Part 3: The Mobile Location Client Chapter 10. Client Platforms and Protocols Platforms Client Protocols and Languages Internationalization and Localization Endnotes Part 4: Mobile Location Service Technology Chapter 11. Mobile Location Service Applications Navigation and Real-Time Traffic Emergency Assistance Concierge and Travel Services Location-Based Advertising and Marketing Location-Based Billing Endnotes Part 5: Advanced Topics Chapter 12. Digital Map Databases 'Best of Breed' Maps Endnotes Appendix A. Abbreviations Appendix B. Geography Markup Language Geography Markup Language 2.0 OpenGIS® Implementation Specification, 20 February 2001 1 Representing Geographic Features 2 Overview of GML 3 The Conceptual Framework 4 Encoding GML 5 GML Application Schemas 6 Worked Examples of Application Schemas (Non-Normative) 7 Profiles of GML Appendix A: The Geometry Schema, V2.06 (Normative) Appendix B: The Feature Schema, V2.06 (Normative) Appendix C: The Xlinks Schema (Normative) Appendix D: References Appendix E: Revision History Appendix C. LIF Mobile Location Protocol LIF TX 101 Specification: Version 3.0.0, 6 June 2002 Appendix D. Platform for Privacy Preferences (P3P) The Platform for Privacy Preferences 1.0 (P3P1.0) Specification W3C Working Draft 28 September 2001 1 Introduction 2 Referencing Policies 3 Policy Syntax and SemanticS 4 Compact Policies 5 DATA SCHEMAS 6 Appendices Appendix E. Internet Resources Application Servers Association Billing Client Commerce Developer Tools E112 E911 Emergency Services E-OTD Ericsson Mobile Positioning System General GIS Geocoding Geocoding/Soundex GPS GML Java Java Location Services Localization Localization Association Location Pattern Matching Mapping Map Projection Microsoft .NET Nokia Gateway Mobile Location Center Personalization/Privacy Position Augmentation/Dead Reckoning Positioning Positioning and Privacy Privacy Privacy/CRM Provisioning Road Pricing Security Security and LDAP Server Sizing Standards Traffic/RDS?TMC WAP Wireless Wireless Association Wireless Security References