This appendix provides a brief introduction to APPEL. Detailed information about APPEL can be found at the W3C Web site  . The official public working draft is from August 1998. The information about APPEL in this chapter was taken from the January 1999 draft. This draft is still in progress and has not been released yet. Like P3P, APPEL is still in progress and the information presented in this chapter might not be consistent with publicly available information at the W3C's Web site or later versions of the APPEL working draft. Despite this fact, the information in the following sections is still relevant and will provide a brief overview of the features and goals of APPEL. Sample APPEL documents and the explanation of APPEL's underlying grammar are used to illustrate the design and use of APPEL.
APPEL is a language for describing collections of preferences regarding P3P proposals between P3P agents. Using this language, a user can express his preferences in a set of preference-rules (called a ruleset), which can then be used by his user-agent to make automated or semi-automated decisions regarding the exchange of data with P3P enabled Web sites. APPEL complements the P3P specification as described in Appendix B, Platform for Privacy Preferences Project (P3P) .
APPEL can be seen as an ordered rule-based language to express a user's preferences regarding the release of personal information. In comparison, the P3P 1.0 specification provides a syntax for specifying proposals and a protocol and associated syntax for exchanging information between Web sites and user agents. The concept behind using P3P in conjunction with APPEL is that of a rule evaluator. In a P3P transaction, the rule evaluator checks incoming P3P proposals against a user's preferences which are expressed in APPEL. The result of rule evaluation determines which action the user agent will take in the current P3P transaction. This can vary between a seamless acceptance of the proposal, a warning or a seamless rejection, among others. The current APPEL working draft specifies the following things:
APPEL defines a user's preferences with one or more rules, a so-called ruleset. These rulesets are represented as XML  documents which follow the same conventions as generic XML. Whereas P3P is exchanged in real time, there is no such intention for APPEL rulesets to be exchanged by special means such as the HTTP extension mechanism.
In order to facilitate the rapid development of prototype implementations of APPEL, the respective W3C working group decided to divide APPEL into a Level 1 specification (basic privacy preferences) and a more sophisticated and detailed Level 2 specification (the rest of the requirements of the latest working draft). The following sections give an overview of APPEL level 1 and 2 and explain the differences.
Both levels share the same denotion of a rule. A rule is defined by a behavior and one or more expressions. During rule evaluation, the rule's expressions will be checked against the evidence (usually a P3P proposal). If all the expressions evaluate to true, the rule's behavior specifies the action to be taken by the user agent. The two APPEL levels differ in the structure of rulesets as well as the number of attributes and values ruleset elements can have. The following sections illustrate the two grammars and the concept of rule evaluation.
The rules (rule, 3) in the ruleset are encapsulated by XML elements. These elements follow the syntax model of the Resource Description Framework (RDF)  . Each of the APPEL rules specifies a behavior (6), other optional attributes (4), and at least one expression (7).
An APPEL rule evaluator will be invoked by a P3P enabled application. This application activates the rule evaluator by providing various pieces of evidence (a P3P proposal, a Unified Resource Identifier (URI), etc.) and an APPEL ruleset.
Rule evaluation is performed with respect to the evidence provided. Each rule is checked against the evidence in the order in which the rules appear in the ruleset. Rule evaluation ends when a rule fires (is satisfied) or when there are no more rules to evaluate. If a rule fires during rule evaluation, the rule's behavior will be returned by the rule evaluator. If no rule fires during rule evaluation the rule evaluator should return an error. A rule can fire if any of the available evidence satisfies the rule. A piece of evidence satisfies a rule when all of the rule's expressions evaluate to true. APPEL level 1 features two types of expressions which can be used in a rule to match available evidence. Simple Expressions are used to match attributes of arbitrary XML elements and their respective values, such as
The way rule evaluation is performed on these expressions varies depending on the rule's behavior. For example if the rule's behavior is seamless-accept rule evaluation uses a much stricter matching process for multi-valued simple expressions. In such a rule, VOC:purp="0,1,2" can only be matched by a proposal that specifies only the values 0, 1, or 2 (or any combination of these) but will not be matched by any proposal that specifies other values. The other types of rules (seamless-reject, info-prompt, and warn-prompt) would be matched even if the evidence contained values other than 0, 1 or 2, as long as at least one of the values is present. This can be understood as an ONLY-OR matching for seamless-accept rules and a simple OR matching for the other types of rules. Rule evaluation also differs for data reference expression matching (ONLY-OR-NONE compared to OR). APPEL's matching semantics are the most complex part of the APPEL specification. The sensitive nature of APPEL's domain, i.e. personal information, made it necessary to make a number of exceptions to the standard matching semantics. A complete description of these semantics would exceed the scope of this introduction. For more detailed information about rule evaluation, please refer to the latest APPEL working draft at the W3C Web site and the next section which illustrates a sample APPEL level 1 ruleset.
The following APPEL level 1 ruleset illustrates the use of the four kinds of APPEL rules. The rules are self-descriptive (see description-attributes). For information about thevarious P3P elements and attributes please refer to the P3P specification at the W3C Web site or see Appendix B, A P3P Preference Exchange Language (APPEL) .
The first rule (seamless-accept) of the APPEL level 1 ruleset as shown in Figure C-1 on page 113 will fire if the P3P proposal in the evidence collects only the user's clickstream data, and an automatically created identifer (ID.PUID). The rule only allows read access in a non-identifiable matter. Furthermore, it requires the P3P proposal to specify a disclosure statement. If a P3P proposal matches all of the above conditions, the rule evaluator will return the behavior seamless-accept and the user agent can agree to the proposal automatically.
The second rule (info-prompt) will fire if a P3P proposal asks for any part of a user's name for the specified purposes  . The behavior indicates that the proposal is not violating the user's privacy preferences, but the user agent should inform the user and have the user decide whether to accept the proposal or not.
The third rule (seamless-reject) will be satisfied by every proposal which indicates that it collects data which is then be used in an identifiable manner and given out to third parties. When this rule is satisified, it indicates that the provided evidence is not acceptable and that the user agent should either abort the current transaction automatically or seamlessly reject the received P3P proposal (by sending a SORRY message).
The last rule (warn-prompt) will fire in any case where the evidence does not satisfy any of the previous rules. If this rule fires during rule evaluation, the user agent should inform the user that the rule evaluator detected a potential for violations of the user's privacy preferences in the received proposal. It is still the user's decision though whether to agree to the proposal or not.
Basically, rule evaluation in APPEL level 2 works the same way as in APPEL level 1. Because of the additional structural information in APPEL level 2 rulesets (i.e., groups), rule evaluation first tries to find the right group by checking the respective triggers. The groups are checked in the order in which they appear in the ruleset. Once a trigger evaluates to true, the respective rule becomes active and its rules are evaluated in the order in which they appear in the group. All other groups and their rules are ignored for the rest of the process, even if no rule of the active group can fire. If no rule within the active group can fire or no group can become active, the rule evaluator returns with an error. Evaluating the rules of the active group works as in level 1 with a few modifications due to the additional quantifiers, operators and optional rules, expressions, and behaviors. The following section illustrates a sample APPEL level 2 ruleset.
The first group will become active during rule evaluation if the current transaction is performed over a secure connection and the received proposal covers the realm of my bank. The rules of the first group were omitted for clarity. The second group is the default group which will always become active if the first group could not become active. This group should always be at the end of the ruleset, otherwise the groups listed after the default group will never become active. Please refer to the latest APPEL working draft  available at the W3C Web site. This document covers all the details about the different APPEL levels as well as a more sophisticated APPEL level 2 ruleset.