Namespaces
Before I talk more about schemas, I need to cover a W3C Recommendation called "Namespaces in XML," which you can find at http://www.w3.org/TR/REC-xml-names/.
Namespaces have two basic purposes: to enable the sharing of schema structures and datatypes and to uniquely qualify element names in a multischema environment. Namespaces are designed to solve the problem of data sources having elements with the same name but different meanings.
Namespaces point to schemas that contain information about the document you are using. You access this functionality by declaring a namespace and providing information that allows the parser to access the resource where it lives.
Consider the invoice example shown in Listing 4-1. Since the invoice is for books, one of the elements in the body of the invoice is title, meaning the title of a book. However, in the schema that contains the address block, the element title means the salutatory title of the person ordering the book (Ms., Mr., Dr., Esq., Potentate, and so on). These two title elements have distinct meanings, yet they both have the same element name. We want to process them in different ways, but we run the risk of confusing one element with the other.
Listing 4-1. Namespace collision results in an ambiguous situation because two elements with different meanings have the same name. In this case, a person's salutatory title and the title of a book.
|
We need some way of addressing each element individually and processing it properly, without the ambiguity of namespace collision, so we use namespace declarations. A namespace declaration must appear before or in the first element that comes from that namespace. The namespace declaration looks like an attribute on a start tag. All namespace declarations begin with xmlns, followed by an optional local space name (more on space names later).
The value of the namespace declaration attribute is a URL that points to a schema that defines the document.
NOTE
The W3C namespace specification notes that "The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). An example of a syntax that is designed with these goals in mind is that for Uniform Resource Names [RFC2141]. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals."
The following invoice start tag contains an example of a namespace for our invoice:
<invoice xmlns="http://architag.com/schemas/invoice.xdr"> |
The application that reads the invoice document can then go to the resource listed, retrieve the schema, and validate the structure of the document according to the rules therein. Since this namespace declaration is on the root element of the document, it remains active for the entire scope of the document—unless another namespace overrides it. (I'll explain that later.)
The namespace declaration applies to the element in which it is declared as well as to all child elements of that element. Thus we can have as many namespaces in a document as we want, but only the most recently declared namespace will be current.
What do I mean by most recently declared? Remember that XML is a hierarchical syntax. All elements in a document are descendants of the root element. Elements inside the root relate to each other through a hierarchical structure. A namespace applies to all elements inside the parent, unless another namespace declaration overrides it. That overriding declaration lives for as long as the element in which it is declared remains open.
Consider our invoice. We defined an invoice with a hole into which we can later drop an address block. This kind of structure is called an open content model because it is open for the implementer to fill later. The following document is an example of the namespace scoping in effect:
Listing 4-2. An invoice that uses namespaces to "plug-in" an address block at the appropriate place.
|
Notice in Listing 4-2 that the root element, invoice, contains a namespace attribute and that the child element address contains its own namespace attribute. If you go to the xmlns document, you'll find that the invoice namespace defines elements like number, customer, and date. If you look at the address namespace, you'll find elements like street, city, state, and zipcode defined.
Any time you declare a namespace, the child elements within the scope of the parent become part of that namespace. This is called the default namespace. But what if you want to mix namespaces within an element scope? What if, for example, you want the date element inside the invoice element to have a data type declared somewhere else?
In that case, you can declare another namespace in the invoice element's start tag. Since you can declare only one default namespace at a time, the second namespace must indicate the namespace prefix. You append this prefix to the element names in the start tags and end tags of the elements that are part of that namespace.
Listing 4-3 shows the same invoice with multiple namespace prefixes. The two namespaces indicate where to find element descriptions (schema).
Listing 4-3. An invoice that uses multiple name spaces.
|
Notice the second namespace declaration on line 3. This declares a namespace that you can use anywhere within the scope of the invoice element, but you must explicitly indicate the namespace on the element's start tags and end tags or attribute names. On line 6, an attribute on the date element uses the dt namespace. In this case, the type attribute in the datatype schema is set to date. Notice that the dt namespace is also used on attributes in the body element on lines 14 through 16.
Another way to specify the namespace is to use the namespace prefix on all elements. That is, get rid of the default namespaces all together, as shown in listing 4-4.
Listing 4-4. The namespace prefix can be used in front of any element. This shows which elements belong to which namespaces, but the coding is quite ungainly.
|
EAN: 2147483647
Pages: 150