Namespaces and scoping

XACML elements like policies, policysets and rules are given abstract identifiers (names) that are collected into namespaces. Different namespaces may reside in different files or within the same file. Namespaces can also be nested and their names accessed using the usual dot-notation from languages like Java and C#.

An ALFA file may contain any number of namespace declarations. All policies and policy sets and other declarations must always be inside a namespace.

Example: The following code snippet defines policy p within namespace B, which in turn resides within namespace A. Comments are marked using '//' and '/*..*/' as is customary.

namespace A {
    // (2)
    namespace B {
        // (1)
        policy p {...}
    }
}
/* (3) */

To refer to policy P from code point (1), we need to use its name "p"; from code point (2). If no 'import' statement is added, we would use the qualified name "B.p"; and "A.B.p" from code point (3).

Names from a namespace can be imported into another namespace to avoid having to indicate the chain of namespaces.

For example:

namespace A {
    namespace B {
        policy p {...}
    }
    import B.p
    /* (4) */
}
       
namespace C {
    import A.B.*
    /* (5) */
}

At points (4) and (5), policy p may now be referred to simply as "p".

Namespaces are also used to construct default identifiers for policies, policy sets and rules.

In XACML, a policy (set) and rule are uniquely identified using a URI. When the default mapping from qualified names to URIs is to be overridden, the syntax admits associating a URI constant to a name.

Examples:

policy p = "urn:example:policy:p" {...}
policyset q = "urn:example:policy-set:q" {...}