Copyright �2000 W3C� (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document complements the P3P1.0 specification by specifying a language for describing collections of preferences regarding P3P policies between P3P agents. Using this language, a user can express her preferences in a set of preference-rules (called a ruleset), which can then be used by her user agent to make automated or semi-automated decisions regarding the acceptability of machine-readable privacy policies from P3P enabled Web sites.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is a W3C Working Draft of the P3P Preference Interchange Language Working Group, for review by W3C members and other interested parties. This document has been produced as part of the P3P Activity, and may eventually be advanced toward W3C Recommendation status. Being a Working Draft document, this specification may be updated, replaced, or obsoleted by other documents at any time. It is therefore inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress." A list of current W3C working drafts can be found at http://www.w3.org/TR/.
This Working Group has considered a number of different approaches to developing a P3P preference interchange language and has decided to document one approach and solicit feedback on it. The group may consider other approaches, including more general-purpose languages (for example, XML or RDF query languages). We encourage the development of experimental implementations and prototypes so as to provide feedback on the specification. However, this Working Group will not allow early implementations to affect their ability to make changes to future versions of this document.
This version of the APPEL language relies on ordered rules. The Working Group is particulary interested in feedback on how to improve this mechanism in terms of better supporting merging and editing of rulesets. Please note that the examples in this draft document are based on the 4 April 2000 version of the P3P Specification and that such examples might need to be updated should a revised version of the P3P Specification appear.
This draft document will be considered by W3C and its members according to W3C process. This document is made public for the purpose of receiving comments that inform the W3C membership and staff on issues likely to affect the implementation, acceptance, and adoption of P3P.
Comments should be sent to [email protected]. This is the preferred method of providing feedback. Public comments and their responses can be accessed at http://lists.w3.org/Archives/Public/www-p3p-public-comments/. Alternatively, if you do not wish your comment to be made public, you can send your comment to [email protected]. In this case, your comments will only be accessible to W3C members (at http://lists.w3.org/Archives/Member/p3p-comments/).
This document specifies a language for describing collections of preferences regarding P3P policies between P3P agents. Using this language, a user can express her preferences in a set of preference-rules (called a ruleset), which can then be used by her user agent to make automated or semi-automated decisions regarding the acceptability of machine-readable privacy policies from P3P enabled Web sites.
Note: This language is intended as a transmission format; individual implementations must be able to read and write their specifications in this language, but need not use this format internally.
This language complements the P3P1.0 specification. Much of the underlying logic is based on PICSRules. We hope in time that this will merely be an application of XML (XML-data) rules or query languages.
Policies can be parsed automatically by user agents -- such as web browsers, browser plug-ins, or proxy servers -- and compared with privacy preferences set by the user. Depending on those preferences, a user agent may then simply display information for the user, generate prompts or take other actions.
A basic P3P interaction might proceed as follows:
Primarily, we envision this language will be used to allow users to import preference rulesets created by other parties and to transport their own rulesets files between multiple user agents. User agent implementors might also choose to use this language (or some easily-derived variation) to encode user preferences for use by the rule evaluators that serve as the decision-making components of their user agents.
The working group limited the scope of APPEL as follows:
In order to facilitate the rapid development of prototype implementations of the language the working group decided to first release a Level 1 specification designed to express only basic privacy preferences and later prepare a more detailed Level 2 specification that would implement the rest of the requirements outlined above. Specifically, APPEL Level 1 limits the requirements to
The remainder of this document will discuss the thus simplified version of APPEL, refered to as the Level 1 specification. See Appendix A for a list of further planned extensions regarding the full APPEL syntax, from here on refered to as the Level 2 specification.
As a quick reference, the following figure shows an example policy that features most of the elements and attributes of an XML P3P 1.0 policy. Please refer to section 3. Policy Syntax and Semantics of the P3P 1.0 Specification for details on the individual elements and their usage.
<POLICY xmlns="http://www.w3.org/2000/P3Pv1"> <ENTITY> <DATA name="business.name">TheCoolCatalog</DATA> <DATA name="business.contact-info.postal.street.line1">123 Main Street</DATA> <DATA name="business.contact-info.postal.city">Bethesda</DATA> <DATA name="business.contact-info.postal.stateprov">MD</DATA> <DATA name="business.contact-info.postal.postalcode">20814</DATA> <DATA name="business.contact-info.postal.countrycode">US</DATA> </ENTITY> <DISPUTES-GROUP> <DISPUTES resolution-type="independent" service="http://www.PrivacySeal.org" description="PrivacySeal.org" image="http://www.PrivacySeal.org/Logo.gif"/> </DISPUTES-GROUP> <DISCLOSURE discuri="http://www.TheCoolCatalog.com/PrivacyPractice.html" access="none"/> <STATEMENT> <CONSEQUENCE-GROUP> <CONSEQUENCE>a site with clothes you would appreciate</CONSEQUENCE> </CONSEQUENCE-GROUP> <RECIPIENT><ours/>/RECIPIENT> <PURPOSE><custom/><develop/></PURPOSE> <RETENTION><indefinitely/></RETENTION> <DATA-GROUP> <DATA name="dynamic.cookies" category="state"/> <DATA name="dynamic.miscdata" category="preference"/> <DATA name="user.gender"/> <DATA name="user.home." optional="yes"/> </DATA-GROUP> </STATEMENT> <STATEMENT> <RECIPIENT><ours/></RECIPIENT> <PURPOSE><admin/><develop/></PURPOSE> <RETENTION><indefinitely/></RETENTION> <DATA-GROUP> <DATA name="dynamic.clickstream.server"/> <DATA name="dynamic.http.useragent"/> </DATA-GROUP> </STATEMENT> </POLICY>
or
,
and
, or-exact
and and-exact
. See
section 5.4.3 Connectives for
more details.<POLICY>
and
<APPEL:REQUEST>
elements to be used as the
(top-level) expression in a rule.
<OTHERWISE>
element.
<APPEL:RULE>
element. In APPEL Level 1, the
top-level expression can only be a <POLICY>
or
<APPEL:REQUEST>
element, or the degenerate expression.<APPEL:RULE
behavior="...">rule</APPEL:RULE>
In addition, this specification uses the same words as RFC 2119 [RFC2119] for defining the significance of each particular requirement. These words are:
The scope of the rule is determined by the opening and closing
elements of an <APPEL:RULE>
element. The
evaluator returns the behavior (as specified in its
behavior
attribute) of the rule that fired on the basis of
the evidence discussed above as well as a copy of the policy that
triggered the rule. The latter might not necessarily be identical
with the original policy found in the evidence, particulary if it
contained optional elements that were not matched by the rule. In
addition, the rule evaluator may optionally return an explanation
string (suitable for user display), the name of a persona, and/or
the rule that fired.
Applications should interpret the standard outputs as follows:
Each rule in the ruleset is evaluated in the order in which it appears. Once a rule evaluates to true, the corresponding behavior is returned and rule evaluation ends. User Agents that wish to provide additional information in case a policy is not accepted (such as listing all reasons why it was rejected, not only the first one that led to "reject") might require further evaluation in order to provide such information to the user.
Rulesets should be written so that there is always a rule that will fire. A rule evaluator should return an error if it is called without a ruleset, with an empty ruleset, or if no rule fires. It is up to the calling program to determine what to do if an error is returned; however, calling programs SHOULD NOT treat an error as they would a "accept".
Further information on rule processing can be found in sections 5.1 The Rule Evaluator in a nutshell and 5.2 Rules ordering.
An expression in APPEL is represented by an XML element that can be evaluated to TRUE or FALSE by matching it against the available evidence. An expression always consists of (see figure 2.1 for examples):
Element name only:
|
Element and attribute:
|
Element name, contained elements and
connective:
|
Element name, attributes, contained elements &
connective:
|
Attribute-expressions may take string or numeric values, although APPEL will treat all values as simple strings. APPEL Level 1 supports only the equality operator in attribute-expressions (APPEL Level 2 might additionally offer comparison operators such as "<" less-than and ">" greater-than for matching numeric values).
APPEL offers a single wildcard metacharacter "*"
which closely resembles the wildcard character in many operating
system shells. Attribute expressions can use this metacharacter to
match ranges of values such as <DATA
name="User.*">
(any element from the
"User" data set). Further details are given in sections
5.4.1 Attribute Expressions and 5.4.2 Regular Expression Metacharacters.
<APPEL:OTHERWISE>
. Instead of matching it against the
evidence, the rule evaluator MUST always evaluate this expression
to true. This expression usally appears in the last rule of a
ruleset in order to catch all possible cases that haven't been
matched yet. When multiple attribute expressions and/or contained expressions
are placed within the scope of a single expression, all are matched
within the scope of a single piece of evidence. For example, if a
rule contains a <STATEMENT>
expression that
contains both a
<PURPOSE><develop/></PURPOSE>
expression
and a <RECIPIENT><ours/></RECIPIENT>
expression, then it will only evaluate to true if the P3P policy
contains a statement that both declares local recipients and a
research & development purpose. If both expressions are satisfied, but only in
separate statements, then the expression evaluates to false.
While attribute expressions within an expression are implicitly
ANDed together, a special
connective
attribute is used to govern the matching
semantics of contained expressions.
APPEL supports four such connectives: or, and,
or-exact, and and-exact. If no connective is
given, APPEL defaults to requiring and-exact matches: only
if the elements in the evidence are identical to those
given in the rule, a match is triggered.
The matching of attribute and contained expressions is described in more detail in section 5.4 Matching.
<APPEL:RULESET>
element), it is only
used to demonstrate a small set of example rules.
We will start with a plain text description of the user's (admittedly simple) preferences, followed by a tabular overview of the involved elements and their allowed values. Finally, we will give an example of the corresponding APPEL encoding. Note that each listing in this document features line numbers for ease of reference; they are not part of the actual encoding!
http://www.my-bank.com
, she accepts any data request as
long as her data is not redistributed to other recipients.Please note that some of the cells feature a wildcard symbol "*", while others are empty. APPEL distinguishes between non-referenced attributes and those that are referenced but contain only wildcards. In the former case, the user truly does not care about the attribute, even whether it is included in the policy or not. In the latter case, the user might not care about the attributes value, but at least expects it to have some value. For further details see section 5.4.2 Regular Expression Metacharacters. In row three of our example below, the user does not care about the purpose of the collected clickstream data (hence the empty fields in the table), but requires that some form of dispute-information is present (represented by a wildcard "*" character).
Behavior | Element/Set | URI | Disputes | Purpose | Recipient |
reject | category="physical", or category="demographic", or category="uniqueid" |
same, other, delivery, public or unrelated |
|||
accept | dynamic.http.useragent, dynamic.clickstream.server | * | |||
inform | user.name.* | "PrivacyProtect" and "TrustUs" | current, admin, custom or develop | ||
accept | www.my-bank.com | ours | |||
warn | [otherwise] |
behavior
attribute) first rejects any policies asking for
identifiable data that is distributed to 3rd parties.
Using an explicit match for the request URL, a second rule then
accepts a policy if, when connecting to
www.my-bank.com
, the requested data is only distributed to
the bank and its agents.
Next, an "accept" rule checks to see if only non-identifiable clickstream data and/or user agent information (such as browser version, operating system, etc) is collected, and accepts if dispute information is available.
An "inform" rule then matches any requests for the user's name for non-marketing purposes and eventually initiates a prompt informing the user that a site wants to collect her name under acceptable circumstances.
If none of the other rules matches, a "warn"-rule encapsulating the degenerate expression "APPEL:OTHERWISE" will fire, warning the user to (cautiously) decide on any policy that has not been covered by any of the rules above.
000: <APPEL:RULESET xmlns:APPEL="http://www.w3.org/2000/APPEL" 001: crtdby="W3C" crtdon="13-Nov-1999 09:12:32 GMT"> 002: 003: <APPEL:RULE behavior="reject" 004: description="Service collects personal 005: data for 3rd parties"> 006: <POLICY APPEL:connective="and"> 007: <STATEMENT APPEL:connective="and"> 008: <DATA-GROUP APPEL:connective="or"> 009: <DATA category="physical"/> 010: <DATA category="demographic"/> 011: <DATA category="uniqueid"/> 012: </DATA-GROUP> 013: <RECIPIENT APPEL:connective="or"> 014: <same/><other/><public/><delivery/><unrelated/> 015: <RECIPIENT/> 016: </STATEMENT> 017: </POLICY> 018: </APPEL:RULE> 019: 020: <APPEL:RULE behavior="accept" 021: description="My Bank collects data only for itself 022: and its agents"> 023: <APPEL:REQUEST-GROUP> 024: <APPEL:REQUEST uri="http://www.my-bank.com/*"/> 025: </APPEL:REQUEST-GROUP> 026: <POLICY APPEL:connective="and"> 027: <STATEMENT APPEL:connective="and"> 028: <RECIPIENT APPEL:connective="or-exact"> 029: <ours/> 030: <RECIPIENT/> 031: </STATEMENT> 032: </POLICY> 033: </APPEL:RULE> 034: 035: <APPEL:RULE behavior="accept" 036: description="Service only collects clickstream data"> 037: <POLICY APPEL:connective="and"> 038: <STATEMENT APPEL:connective="and"> 039: <DATA-GROUP APPEL:connective="or-exact"> 040: <DATA name="Dynamic.HTTP.UserAgent"/> 041: <DATA name="Dynamic.ClickStream.Server"/> 042: </DATA-GROUP> 043: </STATEMENT> 044: <DISPUTES-GROUP> 045: < DISPUTES service="*"/> 046: </DISPUTES-GROUP> 047: </POLICY> 048: </APPEL:RULE> 049: 050: <APPEL:RULE behavior="inform" 051: description="Service only collects your name 052: for non-marketing purposes (assurance 053: from PrivacyProtect and TrustUs)"> 054: <POLICY APPEL:connective="and"> 055: <STATEMENT APPEL:connective="and"> 056: <PURPOSE APPEL:connective="or-exact"> 057: <current/><admin/><custom/><develop/> 058: </PURPOSE> 059: <DATA-GROUP APPEL:connective="or-exact"> 060: <DATA name="User.Name.*"/> 061: </DATA-GROUP> 062: </STATEMENT> 063: <DISPUTES-GROUP APPEL:connective="and"> 064: <DISPUTES service="http://www.privacyprotect.com"/> 065: <DISPUTES service="http://www.trustus.org"/> 066: </DISPUTES-GROUP> 067: </POLICY> 068: </APPEL:RULE> 069: 070: <APPEL:RULE behavior="warn" 071: description="Suspicious Policy. Beware!"> 072: <APPEL:OTHERWISE/> 073: </APPEL:RULE> 074: 075: </APPEL:RULESET>
Lines | Explanation |
---|---|
000 - 075 |
APPEL ruleset. Usually a single APPEL ruleset
(i.e., a set of ordered rules enclosed
in an
<APPEL:RULESET> tag) is installed in a
user agent. Implementations might offer to hold different
rulesets depending on the current user of the system, or on
the persona the user wants to use during the current
browsing session. The <APPEL:RULESET> element can be tagged
with additional information such as author or date of creation:
[1] ruleset = '<APPEL:RULESET xmlns="http://www.w3.org/2000/APPEL" ' attributes '>' rseq '</APPEL:RULESET>' [2] rseq = 1*rule |
003 - 018 |
"reject" rule. APPEL offers four
distinct kinds of behaviors for
rules: "accept", "reject", "inform" and "warn". Each rule
consists of an
<APPEL:RULE> element surrounding a set of
expressions or the degenerate
expression
<APPEL:OTHERWISE> .
[3] rule = '<APPEL:RULE behavior="' behavior '"' attributes '>' body '</APPEL:RULE>' [5] body = top-expression | '<APPEL:OTHERWISE/>' [6] behavior = 'accept' | 'reject' | 'inform' | 'warn' Each rule can be augmented by a set of attributes. In our example we use the description field to supply a human readable explanation ("Service only collects clickstream data") in case the rule should fire (this could be displayed by the user agent during data transfer, prompting, or could be used for debugging purposes). [4] attributes = [' persona=' quoted-string] [' crtby=' quoted-string] [' crton="' datetime '"'] [' description=' quoted-string] |
006 - 017 |
P3P Policy to match. Most APPEL rules have a P3P
policy as the matching expression inside a
<RULE> element. Elements and attribute values
that the rule should match on are simply spelled out in the
policy, while wildcards ("*") are used to match a
range of values. Omitting an attribute or element
completely allows the attribute/element to be missing from
the policy supplied by the service (or to be included with
any value).
|
007 - 016 | STATEMENT element match. The
"reject" rule should fire (i.e. reject the policy)
if the service asks for personal data
(<DATA> elements in the categories
physical , demographic or
uniqueid ) that is distributes to 3rd parties
(<RECIPIENT> matching
<same/> , <other/> " or
<published/> ). Note that rules do not
always feature all required elements of a P3P
policy. Given that both the <DATA> and
<RECIPIENT> element match, this reject
rule will match regardless of the purpose
(<PURPOSE> ) specified in the policy. |
006 - 008, ... |
Connectives. Using the
APPEL:connective attribute, the rule author can
explictly specify different matching semantics for the
contained expressions of an element. APPEL supports four
different connectives (or , and ,
or-exact and and-exact ) that
implement different matching semantics. If no connective is
given, the default matching semantics require an
and-exact match between the rule and the available
evidence.
[11] connective = 'APPEL:connective="' conn '"' [12] conn = or | and | or-exact | and-exact |
020 - 033 | Restricted Accept-rule. This
"accept" rule only continues to match the policy if
it has been fetched while requesting a Web resource from
www.my-bank.com . This is because of the
additional
<APPEL:REQUEST> element in the rule body,
which evaluates to false unless the user agent is currently
requesting a resource from the uri listed in the element.
This allows users to easily write rules that only apply to
policies from a restricted set of domains. |
035 - 048 | accept. The "accept" rule
should only allow the release of data if the policy sent by
the service at most declares the collection of user agent
and/or clickstream data. Note that the purpose
(<PURPOSE> ) and recipient element
(<RECIPIENT> ) do not have to
appear in the rule, even though they are required in a P3P
policy statement. |
040 - 041 | Data Elements to match. Because of
the use of the "or-exact "-connective, the "accept" rule
will only match if the statement in the policy does not
contain any additional data references not
contained in the rule. Consequently, a policy requesting any
other element than the ones explicitly enumerated in between
lines 33 and 36 of the ruleset would immediately evaluate the
expression to false (i.e. not accepting the
policy). |
044 - 046 | DISPUTE-resolution information to match. The user wants to make sure that the service included a reference to an organization that can provide assurance about its privacy policy in case disputes should arise. |
050 - 068 | "inform" rule. Although the user agrees to releasing her name for non-marketing purposes to Web Sites that have assurances from both TrustUs and PrivacyProtect, she wants to supervise each individual data transfer. Implementations might offer User Interfaces that allow users to explicitly accept all subsequent data transfers to a particular site, effectively prompting the user only for her first visit to a new site. |
013, 056 | Matching a list of alternatives. In order to match a number of different purposes or recipients, we use either the "or" or the "or-exact" connective and enclose a list of valid alternatives recipients and purposes elements. |
063 - 066 | Matching conjunctive values. In
order to require both assurances from TrustUs and
PrivacyProtect in the policy, the rule lists the same element
(<DISPUTES> ) multiple times (but with
different values in their attributes) together with the
"all" connective in the enclosing
DISPUTES-GROUP element, thus representing a logical
AND between the values. |
070 - 073 | "warn" rule. Since rules
in an APPEL ruleset are ordered, the "warn" rule
only gets evaluated should all preceding rules fail to match
the policy sent by the publisher. If we would reverse the
order of our rules (i.e. putting the
<OTHERWISE> rule at the top), our user agent
would always issue a warning for all incoming policies (see
comment below). |
072 |
Degenerate Expression. Using the degenerate
expression <OTHERWISE> , we can create
"catch-all" rules that are always known to
evaluate to true. Rules containing
<OTHERWISE> should usually be placed at the
end of a ruleset, since all following rules will never be
evaluated. Note that empty rules never match anything.
Rulesets should be written so that for any possible evidence set, there is always a rule that will fire. Thus, if no rule fires, the rule evaluator should return an error. |
[1] ruleset = '<APPEL:RULESET xmlns="http://www.w3.org/2000/APPEL" ' attributes '>' rseq '</APPEL:RULESET>' [2] rseq = 1*rule [3] rule = '<APPEL:RULE behavior="' behavior '"' attributes '>' body '</APPEL:RULE>' [4] attributes = [' persona=' quoted-string] [' crtby=' quoted-string] [' crton="' datetime '"'] [' description=' quoted-string] [5] body = top-expression | '<APPEL:OTHERWISE/>' [6] behavior = 'accept' | 'reject' | 'inform' | 'warn' [7] top-expression = policy | request-group [policy] [8] policy = <[P3P10] policy (optionally with embedded connectives)> [9] request-group = '<APPEL:REQUEST-GROUP ' [connective] '>' 1*request '</APPEL:REQUEST-GROUP>' [10] request = '<APPEL:REQUEST uri="' [URI] as per RFC 2396 '">' [11] connective = 'APPEL:connective="' conn '"' [12] conn = or | and | or-exact | and-exact [13] quoted-string = '"' string '"' [14] string = <[UTF-8] string (with " and & escaped)> [15] datetime = <date/time as per section 3.3 of [RFC 2068]>
Details are described in section 4.2 Elements below. Please see also Appendix 7.3 APPEL Level 2 Specification.
In contrast to P3P policies, APPEL rulesets are not intended to be exchanged in real time by special means such as an HTTP protocol extension. Instead, they should be treated and downloaded like simple files, using any means available depending on the hard- and software setup in use.
Internally, user agents may use any convenient encoding of a user's ruleset (e.g. in binary form), as long as they provide methods to synchronize a user's plain text ruleset file with its internal representation.
<>
brackets, followed by the list of attributes that can appear in the
element. All listed attributes are optional, except when tagged as
mandatory. For more information on the actual usage of
these elements, please refer to section 5.
Semantics as well as section 3. Simple
Example Scenario.
<APPEL:RULESET>
element<APPEL:RULESET>
persona
<RULE>
level.crtby
crton
description
[1] ruleset = '<APPEL:RULESET xmlns="http://www.w3.org/2000/APPEL" ' attributes '>' rseq '</APPEL:RULESET>' [2] rseq = 1*rule [4] attributes = [' persona=' quoted-string] [' crtby=' quoted-string] [' crton="' datetime '"'] [' description=' quoted-string]
<APPEL:RULE>
element<APPEL:RULE>
behavior
(mandatory
attribute)persona
<RULESET>
is used.crtby
crton
description
The top-level expressions directly enclosed by an
<APPEL:RULE>
element MUST always be matched with an
exact
match (see section
5.4.4 Connectives) -- there is no way in APPEL Level 1
to specify a different matching semantics for the topmost
elements.
A rule that only contains a <POLICY>
element,
but no <APPEL:REQUEST>
element, will try to
match policies on any site. A rule that contains both a
<POLICY>
element and an
<APPEL:REQUEST>
element will only match policies at
sites that match the URI given in the
<APPEL:REQUEST>
element. A rule that only contains an
<APPEL:REQUEST>
element, but no
<POLICY>
element, will match if a site does not offer
any P3P policy. A rule with an empty list of expressions will never
get activated. In order to create a default rule which
will trigger if no other (preceding) rule fired, the degenerate
expression <OTHERWISE/>
should be used.
[3] rule = '<APPEL:RULE behavior="' behavior '"' attributes '>' body '</APPEL:RULE>' [4] attributes = [' persona=' quoted-string] [' crtby=' quoted-string] [' crton="' datetime '"'] [' description=' quoted-string] [5] body = top-expression | '<APPEL:OTHERWISE/>' [6] behavior = 'accept' | 'reject' | 'inform' | 'warn' [7] top-expression = policy | request [policy]
<APPEL:OTHERWISE>
element<APPEL:OTHERWISE>
<APPEL:OTHERWISE>
should be the only
expression in a rule. A ruleset should usually contain one and only
one rule featuring the degenerate expression, and such a rule
should be the last one in a ruleset. Users should take care not to
use the <OTHERWISE>
element together with a
accept behavior, which would result in unlimited access to a
user's data repository for sites not covered by the preceding
rules! User agents MUST refuse to accept rulesets with such
"catch-all" accept rules.
[5] body = top-expression | '<APPEL:OTHERWISE/>'
<APPEL:REQUEST>
element<APPEL:REQUEST>
uri
(mandatory
attribute) Together with a <POLICY>
-expression, the
<APPEL:REQUEST>
element (embedded in an
<APPEL:REQUEST-GROUP>
element) can be used to create
rules that only apply to a certain resource or domain. Since both
expressions need to evaluate to true in order for the rule to fire,
any existing <APPEL:REQUEST>
element will limit
the application of the <POLICY>
expression to
the given URI.
In order to list multiple, alternative resources and/or domains
in a single rule, you can embed multiple
<APPEL:REQUEST>
elements in an
<APPEL:REQUEST-GROUP>
element and connect them using
an or
or or-exact
connective.
[7] expression = policy | request | 1*<A chunk of XML code (optionally with embedded connectives)> [8] policy = <[P3P10] policy (optionally with embedded connectives)> [9] request-group = '<APPEL:REQUEST-GROUP ' [connective] '>' 1*request '</APPEL:REQUEST-GROUP>' [10] request = '<APPEL:REQUEST uri="' [URI] as per RFC 2396 '">'
APPEL:connective
attributeAPPEL:connective
APPEL supports four different kinds of connectives:
or
, and
, or-exact
and
and-exact
. Please refer to section 5.4.3 Connectives for a description of
their semantics. If no APPEL:connective
is given,
APPEL's matching semantics default to an and-exact
match: All of the contained�expressions must
appear in the evidence, and no additional elements must be
present.
[11] connective = 'APPEL:connective="' conn '"' [12] conn = or | and | or-exact | and-exact
The rule evaluator MUST return a behavior (i.e., one of the four standard behaviors "accept", "reject", "inform" or "warn") that the calling program should carry out, as well as a copy of the policy that triggered the rule. Please note that the latter might not necessarily be identical with the original policy found in the evidence, particulary if it contained optional elements that were not matched by the rule! In addition, the rule evaluator MAY optionally return an explanation string (suitable for user display), the name of a persona, and/or the rule that fired.
Each rule in a ruleset is evaluated in the order in which it appears. Once a rule evaluates to true, the corresponding behavior is returned and rule evaluation ends. If no match occurs and all rules have been processed, an error is returned to the calling program.
Rulesets should be written so that for any possible evidence set, there is always a rule that will fire. It is up to the calling program (usually the user agent) to determine what to do if an error is returned; however, calling programs should not treat an error as they would an "accept".
<POLICY>
element, the APPEL
<APPEL:OTHERWISE>
element, as well as the
<APPEL:REQUEST>
element (representing the URI of the
currently requested resource, not the policy URI).
All top-level expressions in a rule are implicitly ANDed
together. Each expression in turn is implicitly ANDed together with
all of its enclosed attribute
expressions. Contained expressions
are by default also ANDed together, unless the rule author
explicitly specified an alternative matching using the
connective
attribute.
All expressions and their sub-expressions (i.e. attribute and
contained expressions) are matched by the rule evaluator against
the elements in the evidence according to the nesting in which they
appear in the rule. For example, a STATEMENT
element
nested inside a POLICY
element in the rule will only
match a STATEMENT
element in the evidence which is
nested inside a matching POLICY
element.
A rule containing no expressions always evaluates to false, a rule containing only the degenerate expression always evaluates to true.
How APPEL evaluates multiple rules in a rulesetThere is no need for logic operators between multiple rules in an APPEL ruleset, since all rules in APPEL are evaluated strictly in order. However, inserting a new rule or changing the order of an existing list of rules can greatly influence the behavior of the user agent!
Care should be taken that only a single rule containing the
degenerate expression <OTHERWISE>
exists and is
placed at the end of the ruleset.
How to specify what to match in a ruleEvery rule in an APPEL ruleset contains a number of top-level expressions which must be in valid XML format. Each expression tries to match a certain piece of evidence, which in APPEL Level 1 can only be in the form of a P3P policy or represent request information such as the resource URI (using the
<APPEL:REQUEST>
element).
All sub-expressions of a single expression are per default
always ANDed together, that is, all attribute and
contained expressions have to evaluate to true in order
for the expression to match. However, using the
APPEL:connective
attribute, the rule author can explictly
specify different matching semantics for the contained expressions
of an element.
Note that connectives only govern the matching of contained
expressions appearing at this level. Should these
contained expressions in turn contain other expressions, they will
be matched using the default matching semantics (i.e.,
exact
) unless another connective
attribute is
used within the contained expression. See section 5.4.3 Connectives for details.
Figure 5.1 below gives the informal definition of the 3 main types of expressions in APPEL.
[1] expression = empty-expression | containing-expression [2] empty-expression = "<" element-name *attribute-expression "/>" [3] containing-expression = "<" element-name *attribute-expression [connective]">" 1*contained-expression "</" element-name ">" [4] element-name = identifier [5] attribute-expression = attribute_name "=" quoted-string [6] contained-expression = expression [7] attribute_name = identifier [8] identifier = <a valid XML identifier> [8] quoted-string = `"` string `"` [9] string = <[UTF-8] string (with " and & escaped)> [10] connective = 'APPEL:connective="' conn '"' [11] conn = or | and | or-exact | and-exact
Note that it is possible in APPEL that multiple expressions in
the rule match one and the same element in the evidence. Rule
evaluators do not need to keep track of which part of the rule
matched which part in the evidence. Instead, each expression can
separately be checked against the available evidence, as shown in
the example below: Both STATEMENT
-expressions in the
rule independantly match the same <STATEMENT>
element in the evidence.
<-- ruleset --> <APPEL:RULE behavior="inform"> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <RECIPIENT APPEL:connective="or-exact"> <ours/> </RECIPIENT> <DATA-GROUP APPEL:connective="or-exact"> <DATA name="user.*"/> </DATA-GROUP> </STATEMENT> <STATEMENT APPEL:connective="and"> <PURPOSE APPEL:connective="or-exact"> <custom/> </PURPOSE> <DATA-GROUP APPEL:connective="or-exact"> <DATA category="online"/> </DATA-GROUP> </STATEMENT> </POLICY> </APPEL:RULE> |
<-- evidence (abbreviated) --> <POLICY> ... <STATEMENT> <RECIPIENT><ours/></RECIPIENT> <PURPOSE><custom/></PURPOSE> <DATA-GROUP> <DATA name="user.home.online.email"/> </DATA-GROUP> </STATEMENT> </POLICY> |
Expressions over elements that are not in the set of
evidence provided by the calling program always evaluate to
false, unless the rule author explicitly used the
APPEL:connective
attribute with either the or
or or-exact
flag. For example, a rule using a (contained)
expression to match a disputes
element without any connectives would always fail unless the
evidence would contain such an element.
On the other hand, elements in the evidence that do not have a
corresponding expression in the rule are always ignored, unless the
rule author explicitly used the APPEL:connective
attribute with either the or-exact
or
and-exact
flag. For example, a rule referencing a P3P policy
containing a disputes element but no disclosure element (and using
no connectives) could possibly match evidence of a P3P policy
featuring both a disputes and a disclosure
element.
Please note that matching any evidence other than a P3P policy
or request information requires the use of APPEL Level 2.
When using APPEL Level 1 all elements other that P3P
policies and APPEL:REQUEST
elements will be ignored
(i.e. do not alter rule evaluation). Also remember that if more
than one P3P policy is available, they should be submitted to the
rule evaluator individually (see 5.1 The Rule
Evaluator in a Nutshell).
How APPEL matches expressions against available evidence
Expressions in APPEL are used to match a rule against the available evidence. For a given element in the rule, an expression can test whether the evidence contains an identical element featuring the same attributes, values, and matching sub-elements. The standard matching semantics for all expressions in APPEL depend on the choice of connective that is used (see section 5.4.3 Connectives below) and can be summarized as follows:
or
and or-exact
connectives)and
and
and-exact
connectives)or
and
and
connectives)or-exact
and and-exact
connectives)Only the = operator may be applied to attribute expressions. All attribute values are treated as strings in APPEL, even if they represent numbers (No P3P element features numeric attribute values, so this shouldn't really matter). In order for an expression to match, all of the attributes and values listed in the expression's attribute expressions have to appear in a single element with the same name in the evidence. Any additional attributes that are found in the evidence but which are not referenced in the rule are ignored.
If a rule requires that a particular attribute appears in an
element without restrictions on the value for that attribute
(including the empty value!), the wildcard character
"*" may be used (e.g. as in
attribute="*"
). However, if a rule does not
require that a particular attribute appear at all, the attribute
should not appear in the rule at all.
Please note that it is not possible in APPEL to write rules
that require that a certain attribute does not appear in
an element of the evidence set (e.g. matching
<DISCLOSURE>
elements without access
attribute), nor that a certain element is absent from the evidence
(e.g. matching policies that do not include a disputes
field).
Using metacharacters with strings allows us to specify ranges
of string-values, for example "*.foo.com
"
for any host in the foo.com domain, or
"*://*"
" for a URI (or at least
something that looks like one). Please note that string values are
always matched from the beginning of the string, unless
the user specified an initial * star symbol. Forcing a
string match from the end is not possible in APPEL Level
1.
Please note also that the wildcard character is only allowed
within quoted strings, not for matching attribute names or element
names, for example such as in <DISPUTES
res*="service">
or <DISP*
resolution-type="service">
! While it can be
applied in the above manner to match ranges of data elements (i.e.
subtrees) when used in data-reference expressions (<DATA
name="user.*"/>), it can not be used to
match a set of data set leafs: <DATA
name="*.zipcode"/>!
or
and
or-exact
and-exact
The top level expressions right below the
<APPEL:RULE>
element are always matched using
exact
matching. Connectives can only be used in elements
below the <APPEL:RULE>
element. If no
connective is given, an exact
match is performed.
Connectives only govern matching of the immediate
contained-expressions, they do not propagate downward
(inheritance). If these contained-expressions in turn contain other
expressions, new connectives need to be specified at that level, or
the default exact
connective applies again.
The different matching semantics that result from the four available connectives are summarized in Figure 5.3 below:
Contained expressions are | |||
---|---|---|---|
ORed | ANDed | ||
Additional evidence | is ignored | or |
and |
alters | or-exact |
and-exact (default) |
optional="yes"
, indicating that the declared
element is not required. In order to allow APPEL rules to handle
optional data elements, rule evaluators MUST be able to selectively
remove optional elements from a policy in the evidence and
repeatedly compare the user's ruleset with the thus altered
evidence. In case of a match after some alteration, the rule
evaluator MUST return a copy of the (altered) policy that
triggered the rule together with the triggered behavior (as
specified in the rule that fired). This allows the user agent to
determine which of the optional elements need to be omitted from
data transfer in order to match the user's preferences.
A simple mechanism for matching a policy with optional data elements against a rule is given below. User agent implementors will probably want to use a more efficient startegy:
<EXTENSION>...</EXTENSION>
tags and feature an
optional
attribute that is used to indicate wheter an
unknown extension can either be safely ignored
(optional="yes"
) or not.
Such extensions, both mandatory and optional, can be matched in
APPEL in very much the same way as optional
<DATA>
elements are matched (compare section 5.4.4 Matching optional data elements): Rule
evaluators MUST be able to selectively remove extension
tags that are tagged as being optional and repeatedly compare the
user's ruleset with the thus altered evidence. In case of a
match after any optional extension has been removed, the rule
evaluator MUST return a copy of the altered policy that triggered
the rule, together with the triggered behavior.
Note that is up to the calling application to determine whether an extension referenced in a P3P policy file is supported or not. This should presumably be done before the rule evaluator is invoked, for example at the same time the available P3P policy is syntactically validated.
P3P categories are attributes of data reference elements which provide hints to users and user agents as to the intended uses of the data. Categories are vital to making P3P user agents easier to implement and use; they allow users to express more generalized preferences and rules over the exchange of their data. Categories have to be included when defining a new element or referring to variable abstract elements such as form data or cookies.
The following sections describe the two different cases that must be supported by an APPEL trust engine: rules that refer to named data reference elements using explicit categories, for example as in
<DATA name="dynamic.cookies"
category="navigation"/>
,
as well as rules that use data reference elements with categories
only, such as
<DATA category="preference"/>
user.bdate.
, is assigned to the
"Demographic
and SocioEconomic Data" category, as defined in the P3P 1.0 Specification. For
such elements an explicit (re-)definition of the category both in a
P3P policy, as well as in an APPEL rulefile, does not make sense
and MUST be ignored by the user agent.
However, for a certain number of elements the base data set does not specify a fixed category but instead requires the author of a P3P policy to explicitly list the categories this element is used for in this particular situation. These elements are called "variable-category data elements, and only for data reference expressions referencing those elements the APPEL rule evaluator must support the additional use of the category attribute.
The following pseudo-code summarizes the steps necessary to match named data reference elements that optionally feature an explicit category attribute:
Category-only data reference elements are
<DATA>
elements that contain only a
category
attribute, but no name
attribute. Upon
encountering such a category-only data reference element in a rule,
an APPEL rule engine must implicitly translate each referenced
category into the list of base elements that belong into that
category, effectively representing the rule as if every element
from the P3P
base data set belonging to this category had been explicitly
listed instead.
Figure 5.4 below shows an example. In addition to any fixed-category data element ("user.home.online.*" and "user.business.online.*") the expansion also needs to take into account any variable-category data elements ("dynamic.cookies" and "dynamic.miscdata") by augmenting them with the proper category.
Any custom data schemes that have been introduced by the service as to belonging to the referenced category will also be matched by this mechanism. Please note again that user agents MUST NOT allow services to override the category of fixed category base elements, such as for example "user.name.first" or "user.home.postal.city".
<APPEL:RULE
behavior="reject"> <!-- This rule matches if an element from the "online" category has been requested --> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <DATA-GROUP APPEL:connective="or"> <DATA category="online"/> </DATA-GROUP> </STATEMENT> </POLICY> </APPEL:RULE> |
<APPEL:RULE
behavior="reject"> <!-- Explicit representation of the rule on the left. --> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <DATA-GROUP APPEL:connective="or"> <DATA name="user.home.online.email"/> <DATA name="user.home.online.uri"/> <DATA name="user.business.online.email"/> <DATA name="user.business.online.uri"/> <DATA name="dynamic.cookies" category="online"/> <DATA name="dynamic.miscdata" category="online"/> </DATA-GROUP> </STATEMENT> </POLICY> </APPEL:RULE> |
It is up to APPEL trust engine implementations whether they explicitly expand rules containing category-only data reference elements, or if they instead augment each data reference element in the evidence with the corresponding category (or with multiple elements each featuring a different category, if multiple categories are defined for the element) and simply match the category attributes directly.
An expression "E" matches a piece of evidence "X" (i.e. a certain XML element in the evidence) if and only if all of the following holds:
- the element names of E and X are identical
- all of E's attribute expressions match attributes of X (additional attributes in evidence X which are not referenced in expression E are ignored)
- [if an
or
connective is given in E] at least one of E's contained expressions (if any) match X's enclosed elements (additional enclosed elements in evidence X which are not referenced in expression E are ignored).- [if an
and
connective is given in E] all of E's contained expressions (if any) match X's enclosed elements (additional enclosed elements in evidence X which are not referenced in expression E are ignored).- [if an
or-exact
connective is given in E] at least one of E's contained expressions (if any) match X's enclosed elements (additional enclosed elements in evidence X which are not referenced in expression E are not ignored).- [if an
and-exact
connective, or if no connective is given in E] all of E's contained expressions (if any) match X's enclosed elements (additional enclosed elements in evidence X which are not referenced in expression E are not
For each expression in the rule, find a match in the evidence such that the following conditions (C1-C3) hold:If a match can be found for every expression, then the rule fires.
C1 the matching evidence is the same type of XML element as the rule expression (i.e. <STATEMENT>, <POLICY>, etc.) C2 for every attribute-expression in the rule expression, an attriubte-expression exists in the evidence with the same attribute name and a value that matches according to the appropriate attribute-expression matching rules If the expressions features an or
connective:C3a for at least one nested XML element contained within the expression, C1 through C3 are satisfied. If the expressions features an and
connective:C3b for each nested XML element contained within the expression, C1 through C3 are satisfied. If the expressions features an or-exact
connective:C3c for each nested XML element in the evidence, C1 through C3 are satisfied. If the expressions features no connective, or an exact
connective:C3d for each nested XML element contained within the expression, and for each nested XML element in the evidence, C1 through C3 are satisfied.
As mentioned in section 1.3 Requirements above, an effort was made to simplify the specification in order to facilitate the implementation of early P3P user agents that would support rulesets expressed in APPEL. By separating a set of extensions (Level 2) from the core language (Level 1) the working group hopes to encourage early adoptions of APPEL, allowing us to gain some first hand experiences with a privacy preference language before finalizing the full feature set of APPEL.
In its Level 2 revision, the working group plans to add the following constructs to the syntax and semantics of the language that have previously been left out (i.e. in Level 1) in order to allow for simple initial implementations:
<POLICY>
elements as well as external elements
such as PICS labels or Protocol features (e.g. "SSL in
use").<APPEL:RULESET xmlns:APPEL="http://www.w3.org/2000/APPEL" crtdby="W3C" crtdon="15-March-2000 10:55:32 GMT"> <APPEL:RULE behavior="warn" description="Service collects some kind of identifiable information"> <POLICY APPEL:connective="or"> <DISCLOSURE access="contact" /> <DISCLOSURE access="other" /> <DISCLOSURE access="contact_and_other" /> <DISCLOSURE access="all" /> <DISCLOSURE access="none" /> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="warn" description="Service collects physical and/or online contact information and/or financial account identifiers and/or other data that may be personally-identifiable"> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <DATA-GROUP APPEL:connective="or"> <DATA category="physical"/> <DATA category="online"/> <DATA category="uniqueid"/> <DATA category="financial"/> <DATA category="other"/> </DATA-GROUP> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="accept" description="service does not collect identifiable data or share data with other parties"> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <RECIPIENT APPEL:connective="and-exact"> <ours/> <RECIPIENT/> <PURPOSE APPEL:connective="or-exact"> <current/><admin/><develop/><custom/><targeting/> </PURPOSE> <DATA-GROUP APPEL:connective="or-exact"> <DATA name="user.*"/> <DATA name="dynamic.*" category="state"/> </DATA-GROUP> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior = "warn" description = "service requests data from your data repository or has a practice that doesn't match your preferences"> <APPEL:OTHERWISE/> </APPEL:RULE> </APPEL:RULESET>
<APPEL:RULESET xmlns:APPEL="http://www.w3.org/2000/APPEL" crtdby="W3C" crtdon="15-March-2000 16:41:21 GMT"> <APPEL:RULE behavior="warn" description="Data may be shared with legal entities following different practices, public fora, or unrelated third parties."> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <RECIPIENT APPEL:connective="or"> <other/><public/><unrelated/> <RECIPIENT/> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="warn" description="Data may be used for marketing, profiling or "other" purposes."> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <PURPOSE APPEL:connective="or"> <contact/><profiling/><other/> </PURPOSE> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="warn" description="Site collects healthcare information."> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <DATA-GROUP APPEL:connective="or"> <DATA category="health"/> </DATA-GROUP> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="inform" description="service does not provide access to identifiable data it collects"> <POLICY APPEL:connective="and"> <DISCLOSURE access="contact" /> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior = "accept" description = "privacy policy matches Privacy And Commerce preferences"> <APPEL:OTHERWISE/> </APPEL:RULE> </APPEL:RULESET>
<APPEL:RULESET xmlns:APPEL="http://www.w3.org/2000/APPEL" crtdby="W3C" crtdon="15-March-2000 16:41:21 GMT"> <APPEL:RULE behavior="accept" description="Service has privacy seal and does not share data with unrelated third parties."> <POLICY APPEL:connective="and"> <DISPUTES-GROUP APPEL:connective="or"> <DISPUTES resolution-service="independent" service="http://www.privacyprotect.org*" /> <DISPUTES resolution-service="independent" service="http://www.trustus.org*" /> </DISPUTES-GROUP> <STATEMENT APPEL:connective="and"> <RECIPIENT APPEL:connective="or"> <ours/><same/><other/><delivery/><public/> <RECIPIENT/> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="warn" description="Service collects data needed for e-commerce activities but may share this data with legal entities following different practices, public fora, or unrelated third parties."> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <PURPOSE APPEL:connective="and-exact"> <current/> </PURPOSE> <RECIPIENT APPEL:connective="or"> <other/><public/><unrelated/> <RECIPIENT/> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="warn" description="Service collects data needed for e-commerce activities but may use it also for marketing, profiling, or "other" purposes."> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <PURPOSE APPEL:connective="and"> <current/> </PURPOSE> <PURPOSE APPEL:connective="or"> <contact/><profiling/><other/> </PURPOSE> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="inform" description="Site collects healthcare information but participates in a seal program."> <POLICY APPEL:connective="and"> <DISPUTES-GROUP APPEL:connective="and"> <DISPUTES resolution-service="independent" service="*" /> </DISPUTES-GROUP> <STATEMENT APPEL:connective="and"> <DATA-GROUP APPEL:connective="or"> <DATA category="health"/> </DATA-GROUP> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="warn" description="Site collects healthcare information but does not participates in a seal program."> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <DATA-GROUP APPEL:connective="or"> <DATA category="health"/> </DATA-GROUP> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="accept" description="Service collects data needed for e-commerce activities only, without sharing with legal entities following different practices, public fora or unrelated third parties. A seal program vouches for this."> <POLICY APPEL:connective="and"> <DISPUTES-GROUP APPEL:connective="and"> <DISPUTES resolution-service="independent" service="*" /> </DISPUTES-GROUP> <STATEMENT APPEL:connective="and"> <PURPOSE APPEL:connective="and-exact"> <current/> </PURPOSE> <RECIPIENT APPEL:connective="or-exact"> <ours/><same/><delivery/> <RECIPIENT/> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="inform" description="service does not provide access to identifiable data it collects"> <POLICY APPEL:connective="and"> <DISCLOSURE access="contact" /> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior = "accept" description = "privacy policy matches Look For The Seal preferences"> <APPEL:OTHERWISE/> </APPEL:RULE> </APPEL:RULESET>
<APPEL:RULESET xmlns:APPEL="http://www.w3.org/2000/APPEL" crtdby="W3C" crtdon="15-March-2000 16:41:21 GMT"> <APPEL:RULE behavior="inform" description="Service collects data for marketing, profiling, or "other" purposes."> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <PURPOSE APPEL:connective="or"> <contact/><profiling/><other/> </PURPOSE> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="inform" description="Service shares information with legal entities following different practices, public fora, or unrelated third parties."> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <RECIPIENT APPEL:connective="or"> <other/><public/><unrelated/> <RECIPIENT/> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior="warn" description="Site collects healthcare information."> <POLICY APPEL:connective="and"> <STATEMENT APPEL:connective="and"> <DATA-GROUP APPEL:connective="or"> <DATA category="health"/> </DATA-GROUP> </STATEMENT> </POLICY> </APPEL:RULE> <APPEL:RULE behavior = "accept" description = "privacy policy matches Information Only preferences"> <APPEL:OTHERWISE/> </APPEL:RULE> </APPEL:RULESET>
The formal grammar of APPEL is given in this specification using a slight modification of [ABNF]. Please note that such syntax is only a grammar representative of the XML syntax: all the syntactic flexibilities of XML are also implicitly included; e.g. whitespace rules, quoting using either single quote (') or double quote ("), character escaping, comments, and case sensitivity. In addition, note that attributes and elements may appear in any order.
The following is a simple description of the ABNF.
name = (elements)
(
element1
element2)
<a>*<b>element
<a>element
<a>*element
*<b>element
*element
[element]
"string"
or 'string'
Other notations used in the productions are:
Lorrie Cranor | AT&T Labs-Research |
Marc Langheinrich (Editor & Chair) | ETH Z�rich |
Massimo Marchiori | W3C |
Joerg Meyer | IBM |
Joseph Reagle | W3C |
Drummond Reed | Intermind |
Mary Ellen Zurko (former Chair) | Iris |