Skip navigation.
Downloads | Product Documentation | Support

XQuery Developer's Guide

# Understanding XML Namespaces

XML namespaces are a mechanism that ensures that there are no name conflicts (or ambiguity) when combining XML documents or referencing an XML element. BEA AquaLogic Data Services Platform (DSP) fully supports XML namespaces and includes namespaces in the queries generated in WebLogic Workshop.

This section includes the following topics:

- Introducing XML Namespaces
- Using XML Namespaces in Data Services Platform Queries and Schemas

# Introducing XML Namespaces

Namespaces provide a mechanism to uniquely distinguish names used in XML documents. XML namespaces appear in queries as a namespace string followed by a colon. The W3C uses specific namespace prefixes to identity W3C XQuery data types and functions. In addition, BEA has defined the `fn-bea:` namespace to uniquely identify BEA-supplied functions and data types.

Table 4-1 lists the predefined XQuery namespaces used in Data Services Platform queries.

Table 4-1 Predefined Namespaces in XQuery

Namespace Prefix | Description | Examples
--- | --- | ---
`fn` | The prefix for XQuery functions. | `fn:data()` `fn:sum()` `fn:substring()`
`fn-bea:` | The prefix for DSP-specific extensions to the standard set of XQuery functions. | `fn-bea:rename()` `fn-bea:is-access-allowed()`
`xs` | The prefix for XML schema types. | `xs:string`

For example, the `xs:integer` data type uses the XML namespace `xs`. Actually, `xs` is an alias (called a prefix) for the namespace URI.

XML namespaces ensure that names do not collide when combining data from heterogeneous XML documents. As an example, consider a document related to automobile manufacturers that contains the element `<tires>`. A similar document related to bicycle tire manufacturers could also contain a `<tires>` element. Combining these documents would be problematic under most circumstances. XML namespaces easily avoid these types of name collisions by referring to the elements as `<automobile:tires>` and `<bicycle:tires>`.

## Exploring XML Schema Namespaces

XML schema namespaces—including the target namespace—are declared in the schema tag. The following is an example using a schema created during metadata import:

>     <xsd:schema targetNamespace="http://temp.openuri.org/SampleApp/CustOrder.xsd" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>     xmlns:bea="http://www.bea.com/public/schemas"
>     elementFormDefault="unqualified" attributeFormDefault="unqualified">
>     	...

The second line declares the target namespace using the `targetNamespace` attribute. It this case, the target namespace is bound to the namespace declared on the fourth line, meaning that all element and attribute names declared in this document belong to:

>     http://www.bea.com/public/schemas

The third line of the schema contains the default namespace, which is the namespace of all the elements that do not have an explicit prefix in the schema.

For example, if you see the following element in a schema document:

>     <element name="appliance" type="string"/>

the element `element` belongs to the default namespace, as do unprefixed types such as `string`.

The fifth line of the schema contains a namespace declaration (`bea`) which is simply an association of a URI with a prefix. There can be any number of these declarations in a schema.

References to types declared in this schema document must be prefixed, as illustrated by the following example:

>     <complexType name="AddressType">
>     	<sequence>
>     		<element name="street_address" type="string"/>

>     		...

>     	</sequence>
>     </complexType>

>     <element name="address" type="bea:AddressType"/>

It is recommended that you create schemas with `elementFormDefault="unqualified"` and `attributeFormDefault="unqualified"`. This enables you to rename a namespace by renaming a single complex element, instead of having to explicitly map every element.

# Using XML Namespaces in Data Services Platform Queries and Schemas

Data Services Platform (DSP) automatically generates the namespace declarations when generating a query. Liquid Data employs a simple scheme using labels ns0, ns1, ns2, and so forth. Although it is easy to change assigned namespace names, care must be taken to make sure that all uses of that particular namespace are changed.

When a return type is created, by default it is `qualified`, meaning that the namespace of complex elements appear in the schema.

Figure 4-2 Schema with Unqualified Attributes and Elements

If you want simple elements or attributes to appear as qualified, you need to use an editor outside WebLogic Workshop to modify the generated schema for either or both `attributeFormDefault` and `elementFormDefault` to be set to qualified.