Free JN0-224 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

Junos OS on-box automation scripts, which include op, commit, and event scripts, are written to process the XML-based data structures of the device's configuration and operational state. The two officially supported languages for this purpose from the options provided are Extensible Stylesheet Language Transformations (XSLT) and Stylesheet Language for an Alternative Syntax (SLAX). XSLT is a W3C standard for transforming XML documents. SLAX is a Juniper-developed language that simplifies XSLT with a syntax resembling C and PERL, making it more intuitive for network engineers to write automation scripts.

A. Perl: While Perl has historical context with Junos, it is not a natively supported language for modern on-box commit, op, or event scripts.

B. Ruby: Ruby is not a supported language for creating on-box automation scripts within the Junos OS environment; it is typically used for off-box automation.

1. Juniper Networks TechLibrary, Automation Scripting User Guide. In the section "Understanding the Junos OS Automation Scripting Environment," the documentation states, "Junos OS automation scripts are written in Extensible Stylesheet Language Transformations (XSLT), Stylesheet Language for an Alternative Syntax (SLAX), or Python." This directly confirms XSLT and SLAX as correct.

Source: Juniper Networks, "Automation Scripting User Guide," (Accessed 2023).

2. Juniper Networks TechLibrary, SLAX and XSLT Scripting. The overview page for this topic explicitly details the use of these two languages for Junos automation. It describes SLAX as an alternate, simpler syntax for XSLT, reinforcing that both are foundational to on-box scripting.

Source: Juniper Networks, "SLAX and XSLT Scripting," (Accessed 2023).

Juniper PyEZ is a Python library that simplifies the management and automation of Junos devices. It is built on top of the NETCONF protocol. NETCONF utilizes a Remote Procedure Call (RPC) model to facilitate communication between a client (the automation script) and the server (the Junos device). PyEZ provides a framework that maps Python methods to the specific RPCs defined by the Junos XML API, allowing developers to execute operational commands and manage configurations without manually constructing the underlying XML RPCs.

A. REST API: PyEZ is fundamentally based on the NETCONF protocol, not the Junos REST API, which is a separate, HTTP-based interface for device management.

B. JET API: The Juniper Extension Toolkit (JET) is used for developing applications that run directly on the Junos device (on-box), whereas PyEZ is an off-box library.

D. XML API: While the Junos XML API defines the structure and vocabulary for the RPCs, the actual communication mechanism that PyEZ uses is the RPC model provided by NETCONF.

1. Juniper Networks TechLibrary, Junos PyEZ Overview. "Junos PyEZ is a microframework for Python that enables you to manage and automate devices running Junos OS. It enables you to connect to a Junos device over a NETCONF session and execute RPCs." (Source: Juniper Networks Official Documentation, Junos OS > Automation > Junos PyEZ)

2. Juniper Networks TechLibrary, Automation Scripting User Guide, Understanding the Junos XML API. "Client applications request information and control the configuration of a device running Junos OS by sending remote procedure calls (RPCs) to the Junos XML protocol server on the device... The Junos XML protocol server is integrated into the Junos OS and does not need to be downloaded separately." (Source: Juniper Networks Official Documentation, Junos OS > Automation > Automation Scripting)

3. Juniper Networks TechLibrary, NETCONF XML Management Protocol Developer Guide, NETCONF Session Overview. "The NETCONF protocol uses a remote procedure call (RPC) paradigm. A client encodes an RPC in XML and sends it to a server. The server responds with a reply that is also encoded in XML." (Source: Juniper Networks Official Documentation, Junos OS > Automation > NETCONF)

Junos automation encompasses various methods for device management. Zero Touch Provisioning (ZTP) is a key automation feature that allows a new device to provision itself automatically upon boot-up. This process is initiated from the device's initial boot sequence, which is accessible and can be managed through the console port, making automated provisioning via the console possible.

The Junos REST API operates on a client-server model. The Junos device acts as the REST API server, listening for HTTP/HTTPS requests. The client is an external application or script that sends these requests to manage the device. Therefore, the REST API client is, by definition, off-box.

A. The Junos REST API client is off-box; the Junos device functions as the server that responds to the client's requests.

B. Automation features like Zero Touch Provisioning (ZTP) initiate during the device's boot process, which is directly accessible and manageable via the console port.

1. Junos OS REST API Guide: In the "Overview of the Junos OS REST API" section, the documentation states, "The Junos OS REST API allows a client application to make HTTP(S) requests to a Junos OS device running the REST API." This explicitly defines the client as a separate application, confirming it is off-box. (Source: Juniper Networks TechLibrary, Junos OS REST API Guide).

2. Understanding Zero Touch Provisioning: The ZTP process is an automated script-driven feature that begins when a device is powered on with a factory-default configuration. The documentation explains, "When a device that supports ZTP is powered on... it attempts to bootstrap and configure itself automatically." This entire boot and bootstrap process is observable and can be interacted with via the console port, thus enabling automated provisioning through it. (Source: Juniper Networks TechLibrary, Software Installation and Upgrade Guide, "Understanding Zero Touch Provisioning" section).

The Junos PyEZ Config utility is the primary tool for managing device configurations. By default, it operates in private edit mode. When a configuration session is initiated, PyEZ creates a private copy of the candidate configuration. This allows an automation script to load, modify, and commit changes without interfering with other users or automation processes that might be simultaneously editing the shared candidate configuration. This behavior provides a safe and isolated environment for programmatic configuration changes, preventing potential conflicts.

A. shared: This is the default configuration mode for interactive CLI users, not for PyEZ. Using this mode in automation could lead to conflicts with other users.

B. dynamic: The dynamic database is used for transient configuration information, such as that provided by DHCP, and is not the default target for user-initiated configuration changes.

D. ephemeral: The ephemeral database is a powerful feature for automation but is not the default. It must be explicitly specified to be used by PyEZ for configuration updates.

1. Juniper Networks TechLibrary, Junos PyEZ APIs, jnpr.junos.utils.config Module.

Reference: In the documentation for the Config class constructor (init), the mode parameter is described as: "The configuration mode. The supported modes are 'private', 'exclusive', 'batch', and 'dynamic'. The default is 'private'."

Link: https://www.juniper.net/documentation/us/en/software/junos-pyez/junos-pyez-developer/junos-pyez/topics/ref/api/jnpr.junos.utils.config.html

2. Juniper Networks TechLibrary, Using the Junos PyEZ Configuration Utility.

Reference: Under the section "Lock the Configuration," the documentation states: "By default, the Config utility uses private edit mode when it locks the configuration." This explicitly confirms the default behavior.

Link: https://www.juniper.net/documentation/us/en/software/junos-pyez/junos-pyez-developer/junos-pyez/topics/task/junos-pyez-configuration-utility-using.html

DevOps culture represents a fundamental shift from traditional, siloed IT structures to a more integrated and collaborative environment. The core of this cultural transformation is centered on people and how they interact. It fosters a mindset of shared ownership, mutual respect, and collective responsibility for the entire service lifecycle. Effective communication is the essential practice that enables this collaboration, breaking down the barriers between development and operations teams. These two aspects—a focus on people and the promotion of open communication—are foundational to establishing a successful DevOps environment.

B. separation of duties: This is a principle of traditional IT models that creates silos, which the collaborative nature of DevOps culture actively seeks to eliminate.

C. use of specific tools: While tools are enablers of DevOps practices, the culture itself is tool-agnostic. The focus is on the principles of automation and collaboration, not on any particular technology.

1. Source: Junos Automation and DevOps (JAUT) Student Guide

Reference: Chapter 1, "Introduction to DevOps," Section: "What is DevOps?".

Details: This section describes DevOps as a cultural movement that emphasizes collaboration, communication, and breaking down silos between development and operations teams. It explicitly frames DevOps as a combination of "people, process, and tools," with the cultural change among people being the most critical starting point.

2. Source: Juniper Networks Official Documentation, "DevOps for Networking"

Reference: Solution Description Page.

Details: Juniper defines DevOps as "a mindset, a culture, and a set of technical practices." This official positioning emphasizes that culture is a primary pillar. The text further explains that this culture is about breaking down organizational barriers between teams (people) to improve the speed and quality of service delivery, which is impossible without enhanced communication.

In Python, the fundamental difference between a list and a tuple is mutability. Lists are mutable, meaning their contents can be changed after they are created (e.g., adding, removing, or modifying elements). They are defined using square brackets []. Tuples, on the other hand, are immutable; once a tuple is created, its elements cannot be altered. Tuples are defined using parentheses (). This immutability makes tuples slightly more memory-efficient and allows them to be used as keys in dictionaries, which lists cannot.

A. This option incorrectly reverses the mutability properties; lists are mutable, and tuples are immutable.

C. This option incorrectly states that lists are immutable and reverses the syntax used for both data types.

D. This option correctly identifies the mutability of each type but incorrectly reverses the syntax used to define them.

1. Official Python Documentation, The Python Tutorial. Section 5. Data Structures.

Section 5.1. More on Lists: "The list data type has some more methods... list.append(x) Add an item to the end of the list." This demonstrates mutability. The syntax a = [66.25, 333, 333, 1, 1234.5] shows the use of square brackets.

Section 5.3. Tuples and Sequences: "Tuples are immutable, and usually contain a heterogeneous sequence of elements... As you see, on output tuples are always enclosed in parentheses..." This confirms immutability and syntax.

2. Guttag, J. V. (2016). Introduction to Computation and Programming Using Python, With Application to Understanding Data (2nd ed.). MIT Press.

Chapter 5, Section 5.2, "Lists and Mutability," page 71: "A list is an ordered sequence of values, where each value is identified by an index. The syntax for expressing literals of type list is [e0, e1, ..., ek]... Unlike strings and tuples, lists are mutable."

Chapter 5, Section 5.1, "Tuples," page 70: "A tuple is an ordered sequence of elements... The empty tuple is written as ()... Tuples are immutable."

3. Juniper Networks Education Services. (2021). Junos Automation and DevOps (JAUT) Course Student Guide.

Module 3: Python for Junos Automation, "Python Data Types" section: This section explicitly details that lists are mutable collections defined with square brackets [], while tuples are immutable collections defined with parentheses (). It emphasizes that the immutability of tuples makes them suitable for fixed collections of data.

The Junos XML schema is the definitive reference for the structure of both configuration and operational data within Junos OS. It is written in the standard XML Schema Definition (XSD) language, and these schema files typically use the .xsd extension. This schema acts as the authoritative contract, defining all valid elements, attributes, and hierarchies that can be used in XML requests to and responses from a Junos device. Therefore, it is the authoritative source for understanding the correct XML format for any configuration or operational command.

A. XLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other formats, not for defining the structure of an XML document.

B. The Junos XML schema can be examined directly from the CLI using the show xml schema command, which displays the schema for configuration hierarchies or RPCs.

1. Juniper Networks TechLibrary, Junos XML API and Scripting Developer Guide, "Understanding the Junos XML Schema": "The Junos XML schema defines the structure and syntax of the XML documents that client applications can use to request and configure information on a Junos device... The Junos XML schema is written in XML Schema Definition (XSD) language." This supports options C and D.

2. Juniper Networks TechLibrary, CLI Explorer, "show xml schema": This document details the show xml schema command, which is used to "Display the XML schema for the specified configuration hierarchy or operational mode command." This directly refutes option B.

3. Juniper Networks TechLibrary, Junos XML API and Scripting Developer Guide, "Junos XML Protocol and Native XML Schemas": "The Junos XML protocol and native XML schemas define the structure of Junos XML tag elements... The Junos XML schemas are written in the standard XML Schema Definition (XSD) language." This reinforces that the format is XSD (Option D) and that it defines the structure (making it authoritative, Option C).

The NETCONF protocol architecture is conceptually divided into four layers. When a NETCONF client sends a request to a server, it utilizes both the operations and messages layers.

The operations layer defines the set of base protocol operations, such as or , which are invoked as Remote Procedure Call (RPC) methods. The client selects an operation from this layer to define the action it wants the server to perform.

The messages layer provides the framing mechanism for the request. It encodes the chosen operation within an element, creating a well-formed message that can be sent to the server. Therefore, both layers are used to construct and send an RPC.

A. A NETCONF client sends RPCs and receives messages. The server receives RPCs. The messages layer is for framing, not the act of receiving.

C. The operations layer defines the methods invoked by an RPC; it does not handle the reception of the message itself.

1. Juniper Networks Official Documentation, "NETCONF XML Management Protocol Overview": This document outlines the four conceptual layers of NETCONF. It states, "The messages layer provides a mechanism for encoding RPCs...within ...elements." It also states, "The operations layer defines a set of base protocol operations that are invoked as RPC methods," listing examples like and . This supports that both layers are used to construct and send an RPC. (Source: Juniper TechLibrary, Automation, NETCONF XML Management Protocol Overview)

2. RFC 6241, "Network Configuration Protocol (NETCONF)", Section 1.1. NETCONF Layers: This RFC defines the standard. It describes the Messages Layer as providing "a simple, transport-independent framing mechanism for encoding RPCs" and the Operations Layer as defining "a set of base protocol operations invoked as RPC methods". This confirms that a client uses the operations layer to define the method and the messages layer to frame it for sending.

The XPath expression //address/name is the correct choice to select only the XML elements containing the IP addresses. The double forward slash // is a recursive operator that finds all

B. //name: This expression is too broad. It selects all elements regardless of their parent, which could lead to selecting unintended data in a more complex XML document.

C. /name: This absolute path expression attempts to select a element that is a direct child of the document's root node, which is incorrect as the root element is .

D. /address/name: This absolute path expression is invalid for the given exhibit because it looks for an

1. Juniper Networks Documentation, "Automation Scripting User Guide": In the section "Using XPath to Specify Addressable Portions of a Configuration," the guide explains the operators. It states, "The double forward slash (//) is a recursive descent operator... The single forward slash (/) is a child operator. It indicates that the node to its right must be a child of the node to its left." This supports that //address/name correctly finds all address elements and then their direct name children.

2. Juniper Networks Documentation, "Junos XML API and Scripting Developer Guide": The "XPath Overview" section details how XPath is used to navigate the Junos OS configuration hierarchy represented in XML. It confirms that // selects nodes anywhere in the hierarchy, while / selects a direct child, validating the logic for choosing //address/name to navigate from an address element to its child name element.

3. W3C Recommendation, "XML Path Language (XPath) Version 1.0": Section 2.5, "Abbreviated Syntax," defines // as the abbreviation for /descendant-or-self::node()/. This formal definition confirms that //address selects

The Junos REST API is a Representational State Transfer interface that provides an alternative to NETCONF for managing Junos devices. Enabling the REST API is a straightforward process, requiring only a few simple commands under the [edit system services] hierarchy, making the configuration simple. The REST API operates over HTTPS and is a distinct management interface from NETCONF, which operates over SSH. As they are separate and parallel interfaces to the Junos management daemon, the REST API does not use, integrate with, or support the NETCONF protocol in its operation.

A. It supports data In CSV format.

The Junos REST API supports data formats such as XML, JSON, and plain text for requests and responses, but it does not natively support CSV.

B. It must use SSH for a connection.

The Junos REST API uses HTTPS for secure client-server communication. SSH is the transport protocol used by the NETCONF API, not the REST API.

1. Juniper Networks TechLibrary, Junos OS REST API Guide, "Overview of the Junos OS REST API": This document states, "The Junos OS REST API allows you to make requests to a Junos device and receive data in XML, plain-text, or JSON format... The Junos OS REST API is accessed through HTTPS..." This reference directly refutes options A and B. It also implicitly supports option C by describing the REST API as a separate interface without any mention of NETCONF integration.

2. Juniper Networks TechLibrary, Junos OS REST API Guide, "Enabling the REST API": This section provides the configuration steps to enable the service. The minimal configuration required is set system services rest https, which demonstrates the simplicity of the setup, thus supporting option D.

3. Juniper Networks TechLibrary, Automation for Junos Devices, "Junos Automation Tools Overview": This overview describes the different automation tools available for Junos OS, including the REST API and NETCONF, presenting them as distinct and separate APIs for device management. This supports the reasoning for option C, as one does not "support" the other; they are parallel interfaces.

The standard and most efficient method for applying unique configurations to multiple devices using Junos PyEZ involves a combination of a templating engine and a structured data file. A Jinja2 template defines the base configuration structure with placeholders for variables. A YAML file is then used to store the unique, per-device data, such as hostnames and IP addresses. A Python script leverages Junos PyEZ to read the YAML data, render the Jinja2 template with that data to create a device-specific configuration, and then apply it to the target machine.

A. an SCP module: The SCP module is a utility for securely transferring files to or from a device. It does not generate or apply the configuration itself.

B. a BSON data file: BSON is a binary-encoded format for JSON-like data. While it can store data, YAML is the human-readable, industry-standard format commonly used and documented for this automation workflow.

1. Juniper Networks TechLibrary, Junos PyEZ Developer Guide, "Using Configuration Templates to Configure Junos Devices": This official guide explicitly details the process. It states, "You can use Jinja2 templates in conjunction with Junos PyEZ to generate a configuration and load it onto a device... You can define the variables in a YAML or JSON file and load the file in the application." This section provides a complete example using a Jinja2 template and a YAML variables file to configure an interface.

2. Day One: Automating Junos with PyEZ, Second Edition, Chapter 4: "Provisioning a New Device": This book demonstrates a practical use case. Page 58 shows creating a YAML file (new-devices.yml) to store device-specific variables (hostname, IP address). Page 59 presents a Jinja2 template (config-template.j2) that uses these variables. The accompanying Python script combines them to generate and load the unique configuration for each device.

Both YAML and JSON are case-sensitive data serialization formats. In both languages, the keys (or names) within a key-value pair are treated as strings, and their comparison is case-sensitive. For example, in a JSON object, the key "hostname" is considered different from "Hostname". Similarly, in a YAML mapping, the key hostname: is distinct from Hostname:. This is a fundamental characteristic of how parsers for both formats interpret and structure data.

A. JSON does not use indentation for structure; it uses braces and brackets. Only YAML relies on indentation to define nesting and hierarchy.

B. Whitespace, specifically indentation, is syntactically significant in YAML for defining structure. In JSON, whitespace outside of string values is ignored.

C. YAML supports single-line comments beginning with a # character. The official JSON specification (RFC 8259) does not include a syntax for comments.

1. Juniper Networks Official Documentation: In the Getting Started with Junos Automation guide, the "Data Serialization and Data Models" chapter explicitly states the properties of these formats. It confirms, "YAML is case-sensitive" and "JSON object members are case-sensitive." It also clarifies that "YAML uses indentation to denote structure" while JSON does not, and that "JSON does not support comments."

Source: Juniper Networks TechLibrary, Getting Started with Junos Automation, Chapter: "Data Serialization and Data Models".

2. Official JSON Standard (RFC 8259): This document defines the JSON format. While it doesn't use the exact phrase "case-sensitive," Section 8.1, "String and Character Issues," recommends that implementations treat two name strings as equal "if and only if they are identical (the same sequence of code points)," which implies case-sensitivity. The grammar in Section 2 also shows whitespace is insignificant between structural tokens.

Source: IETF RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format, Sections 2 ("JSON Grammar") and 8.1 ("String and Character Issues").

3. Official YAML Specification: The YAML 1.2.2 specification details its syntax. It defines the significance of indentation for structure and the use of '#' for comments. The case-sensitivity of keys is inherent in the definition of string equality for mapping keys.

Source: YAML Ain’t Markup Language (YAML™) Version 1.2.2 Specification, Sections 6.1 ("Indentation Spaces") and 3.2.3.3 ("Comments").

4. University Courseware: Reputable computer science courses that cover data structures and web technologies consistently teach these fundamental properties. For example, materials on data exchange formats in web programming courses highlight the case-sensitivity of JSON keys and the syntactic differences (indentation, comments) between JSON and YAML.

Source: General curriculum principles from institutions like MIT OpenCourseWare for courses on web development and data formats (e.g., 6.170 Software Studio).

The Juniper Extension Toolkit (JET) is a modern API framework designed for developing applications that automate network devices. It utilizes high-performance gRPC services for direct, programmatic interaction with the Junos OS. One of its key capabilities is the direct modification of the ephemeral configuration database. This in-memory database allows for rapid, temporary configuration changes without requiring a formal commit, which is ideal for SDN and network automation use cases that JET is built to serve.

B. WebSocket: The WebSocket API in Junos is used for subscribing to and streaming event notifications and telemetry data, not for device configuration.

C. SOAP: While the underlying Junos XML protocol (which can be transported over SOAP) can target the ephemeral database, JET is the modern, purpose-built API for this high-performance function.

D. REST: The standard Junos REST API is designed to interact with the candidate configuration database and does not provide a direct interface for modifying the ephemeral database.

1. Juniper Networks TechLibrary, "Ephemeral Configuration Database User Guide": This guide explicitly states the supported methods for modification. "Clients can use NETCONF, the Junos XML protocol, or Juniper Extension Toolkit (JET) APIs to load data into an instance of the ephemeral database." This directly supports JET as a correct answer. (See section: "Overview of the Ephemeral Configuration Database").

2. Juniper Networks TechLibrary, "Juniper Extension Toolkit (JET) Overview": This document describes JET as the framework for developing applications for network control and management, which includes advanced configuration tasks like interacting with different configuration databases. (See section: "JET Overview").

3. Juniper Networks TechLibrary, "Junos OS REST API Guide": The documentation for the REST API focuses on loading configuration changes into the candidate configuration database, with no mention of direct support for the ephemeral database. (See section: "Configuring the Device Using the REST API").

The NETCONF protocol, as defined in RFC 6241, is structured in four conceptual layers. The content layer contains the configuration and operational data, which is encoded using the Extensible Markup Language (XML). This XML-based encoding applies not only to the data itself but also to the protocol messages, including the Remote Procedure Call (RPC) requests and their corresponding responses and notifications. The entire protocol framework, from the RPC layer up to the content layer, relies on well-formed XML for structuring and exchanging information between the NETCONF client and server.

A. YAML is a data serialization language often used in automation tools like Ansible, but it is not the standard encoding format for NETCONF protocol messages.

C. JSON is the primary encoding format for the RESTCONF protocol, which is a REST-like protocol for accessing YANG-defined data, not for the core NETCONF protocol.

D. HTML is a markup language used for creating and structuring web pages and is not used for network management RPCs or data encoding in NETCONF.

1. RFC 6241: Network Configuration Protocol (NETCONF), Abstract, Page 1. "It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages."

2. RFC 6241: Network Configuration Protocol (NETCONF), Section 4: RPC Layer, Page 17. "All NETCONF messages MUST be encoded in XML and use the UTF-8 encoding."

3. Juniper Networks TechLibrary, "NETCONF XML Management Protocol Developer Guide", NETCONF XML Management Protocol Overview. "The NETCONF XML management protocol is an XML-based protocol that client applications use to request and change configuration information on routing, switching, and security devices."

XML namespaces are a mechanism for preventing naming conflicts by qualifying element and attribute names. They associate a prefix with a Uniform Resource Identifier (URI), which acts as a unique identifier for a specific XML vocabulary. This allows a single XML document to contain elements or attributes with the same local name (e.g., id) from different vocabularies without ambiguity, as each is uniquely identified by its namespace. This is fundamental to protocols like NETCONF, which is used extensively in Junos automation.

A. selectors: Selectors are patterns used in technologies like CSS or XSLT to select specific nodes in an XML/HTML document; they do not define name uniqueness.

B. predicate: A predicate is a part of an XPath expression used to filter a set of nodes based on a condition, not to ensure the uniqueness of their names.

D. XPath: XPath is a query language for navigating and selecting nodes within an XML document; it does not provide a mechanism for creating unique names.

1. Juniper Networks Documentation, NETCONF XML Management Protocol Developer Guide: In the "XML Namespaces Overview" section, it states, "XML namespaces are a mechanism for creating unique element and attribute names in an XML document. A namespace is a collection of names, identified by a Uniform Resource Identifier (URI) reference, that are used in XML documents as element types and attribute names." (Source: Juniper TechLibrary, NETCONF XML Management Protocol Developer Guide, "XML Namespaces Overview").

2. Juniper Networks Documentation, Junos OS Automation Scripting User Guide: When discussing SLAX, the guide explains the necessity of declaring namespaces to use specific functions, such as the jcs: prefix for Junos-specific functions. This demonstrates the use of namespaces to differentiate function libraries and avoid naming collisions. (Source: Juniper TechLibrary, Junos OS Automation Scripting User Guide, "SLAX Namespace and Script Structure").

3. W3C Recommendation, Namespaces in XML 1.0 (Third Edition): The abstract of the official specification states, "XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references." (Source: W3C, "Namespaces in XML 1.0 (Third Edition)", Section 1. Motivation and Summary).