Schemas and Namespaces

One of the big ideas behind schemas was to allow XML processors to validate documents that use namespaces (which DTDs have a problem with). Toward that end, the <schema> element has a new attribute: targetNamespace.

The targetNamespace attribute specifies the namespace to which the schema is targeted—that is, the namespace that it is intended for. This means that if an XML processor is validating a document and is checking elements in a particular namespace, it will know what schema to check, based on the schema's target namespace. That's the idea behind target namespaces: You can indicate what namespace a schema is targeted to so that an XML processor can determine which schema(s) to use to validate a document.

You can also specify whether the elements and attributes that were locally declared in a schema need to be qualified when used in a namespace. We've seen globally declared elements and attributes in schemas—they're declared at the top level in the schema, directly under the <schema> element. All the other elements and attributes declared in a schema—that is, those not declared as direct children of the <schema> element—are locally declared. Schemas allow you to indicate whether locals need to be qualified when used in a document.

Using Unqualified Locals

I'll start looking at how schemas work with target namespaces and locals by beginning with unqualified locals (which don't need to be qualified in a document). To indicate whether elements need to be qualified, you use the elementFormDefault attribute of the <schema> element, and you indicate whether attributes need to be qualified; you use the attributeFormDefault attribute of the same element. You can set the elementFormDefault and attributeFormDefault attributes to either "qualified" or "unqualified".

I'll take a look at an example to see how this works. Here, I'm indicating that the target namespace of a schema is "http://www.starpowder.com/ namespace". I'm also making the W3C XML schema namespace, "http://www.w3.org/1999/XMLSchema", the default namespace for the document so that I don't have to qualify the XML schema elements such as <annotation> and <complexType> with a prefix such as xsd.

However, I have to be a little careful. When an XML processor dealing with this schema wants to check, say, the transactionType complex type, it will need to know what namespace to search—and it won't find the transactionType type in the default namespace, which is the W3C XML schema namespace. For that reason, I'll define a new namespace prefix, t, and associate that prefix with the same namespace as the target namespace. Now I can use t: to prefix types defined in this schema so that an XML processor will know what namespace to search for their definitions.

I'll also indicate that both elements and attributes should be unqualified in this case. Here's what this new schema looks like. (Notice that I qualify types defined in this schema with the t prefix, but not types, such as string, that are defined in the default "http://www.w3.org/1999/XMLSchema" namespace.)

<schema xmlns="http://www.w3.org/1999/XMLSchema"
    xmlns:t="http://www.starpowder.com/namespace"
    targetNamespace="http://www.starpowder.com/namespace"
    elementFormDefault="unqualified"
    attributeFormDefault="unqualified">

    <annotation>
        <documentation>
            Book borrowing transaction schema.
        </documentation>
    </annotation>

    <element name="transaction" type="t:transactionType"/>

    <complexType name="transactionType">
        <element name="Lender" type="t:address"/>
        <element name="Borrower" type="t:address"/>
        <element ref="note" minOccurs="0"/>
        <element name="books" type="t:books"/>
        <attribute name="borrowDate" type="date"/>
    </complexType>

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

    <complexType name="address">
        <element name="name" type="string"/>
        <element name="street" type="string"/>
        <element name="city" type="string"/>
        <element name="state" type="string"/>
        <attribute name="phone" type="string"
            use="optional"/>
    </complexType>

    <complexType name="books">
        <element name="book" minOccurs="0" maxOccurs="10">
            <complexType>
                <element name="bookTitle" type="string"/>
                <element name="pubDate" type="date" minOccurs='0'/>
                <element name="replacementValue" type="decimal"/>
                <element name="maxDaysOut">
                    <simpleType base="integer">
                        <maxExclusive value="14"/>
                     </simpleType>
                </element>
                <attribute name="bookID" type="t:catalogID"/>
            </complexType>
        </element>
    </complexType>

    <simpleType name="catalogID" base="string">
        <pattern value="d{3}-d{4}-d{3}"/>
    </simpleType>

</schema>

So how does a document that conforms to this schema look? Here's an example—note that locals are unqualified, but I do need to qualify globals such as <transaction>, <note>, and <books>. Note also that the namespace of this document is the same as the target namespace of the schema that specifies its syntax, as it should be.

<?xml version="1.0"?>
<at:transaction xmlns:at="http://www.starpowder.com/namespace"
    borrowDate="2001-10-15">
    <Lender phone="607.555.2222">
        <name>Doug Glass</name>
        <street>416 Disk Drive</street>
        <city>Medfield</city>
        <state>MA</state>
    </Lender>
    <Borrower phone="310.555.1111">
        <name>Britta Regensburg</name>
        <street>219 Union Drive</street>
        <city>Medfield</city>
        <state>CA</state>
    </Borrower>
    <at:note>Lender wants these back in two weeks!</at:note>
    <at:books>
        <book bookID="123-4567-890">
            <bookTitle>Earthquakes for Breakfast</bookTitle>
            <pubDate>2001-10-20</pubDate>
            <replacementValue>15.95</replacementValue>
            <maxDaysOut>14</maxDaysOut>
        </book>
        .
        .
        .
    </at:books>
</at:transaction>

Using Qualified Locals

You can also require that locals be qualified. Here's an example schema that requires element names to be qualified in conforming documents:

<schema xmlns="http://www.w3.org/1999/XMLSchema"
    xmlns:t="http://www.starpowder.com/namespace"
    targetNamespace="http://www.starpowder.com/namespace"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">

    <annotation>
        <documentation>
            Book borrowing transaction schema.
        </documentation>
    </annotation>
    .
    .
    .

What does a document that conforms to this schema look like? Here's an example—note that I qualify all elements explicitly:

<?xml version="1.0"?>
<at:transaction xmlns:at="http://www.starpowder.com/namespace"
    borrowDate="2001-10-15">
    <at:Lender phone="607.555.2222">
        <at:name>Doug Glass</at:name>
        <at:street>416 Disk Drive</at:street>
        <at:city>Medfield</at:city>
        <at:state>MA</at:state>
    </at:Lender>
    <at:Borrower phone="310.555.1111">
        <at:name>Britta Regensburg</at:name>
        <at:street>219 Union Drive</at:street>
        <at:city>Medfield</at:city>
        <at:state>CA</at:state>
    </at:Borrower>
    <at:note>Lender wants these back in two weeks!</at:note>
    <at:books>
        <at:book bookID="123-4567-890">
            <at:bookTitle>Earthquakes for Breakfast</at:bookTitle>
            <at:pubDate>2001-10-20</at:pubDate>
            <at:replacementValue>15.95</at:replacementValue>
            <at:maxDaysOut>14</at:maxDaysOut>
        </at:book>
        .
        .
        .
    </at:books>
</at:transaction>

Another way of creating a document that conforms to this schema is to replace the explicit qualification of every element with an implicit qualification by using a default namespace. Here's what that looks like:

<?xml version="1.0"?>
<transaction xmlns="http://www.starpowder.com/namespace"
    borrowDate="2001-10-15">
    <Lender phone="607.555.2222">
        <name>Doug Glass</name>
        <street>416 Disk Drive</street>
        <city>Medfield</city>
        <state>MA</state>
    </Lender>
    <Borrower phone="310.555.1111">
        <name>Britta Regensburg</name>
        <street>219 Union Drive</street>
        <city>Medfield</city>
        <state>CA</state>
    </Borrower>
    <note>Lender wants these back in two weeks!</note>
    <books>
        <book bookID="123-4567-890">
            <bookTitle>Earthquakes for Breakfast</bookTitle>
            <pubDate>2001-10-20</pubDate>
            <replacementValue>15.95</replacementValue>
            <maxDaysOut>14</maxDaysOut>
        </book>
        .
        .
        .
    </books>
</transaction>

So far, we've indicated that all locals must either be qualified or unqualified. However, there is a way of specifying that individual locals be either qualified or unqualified, and you do that with the form attribute.

Here's an example; in this case, I'll leave all locals unqualified, except the bookID attribute, which I'll specify must be qualified:

<schema xmlns="http://www.w3.org/1999/XMLSchema"
    xmlns:t="http://www.starpowder.com/namespace"
    targetNamespace="http://www.starpowder.com/namespace"
    elementFormDefault="unqualified"
    attributeFormDefault="unqualified">

    <annotation>
        <documentation>
            Book borrowing transaction schema.
        </documentation>
    </annotation>
    <element name="transaction" type="t:transactionType"/>

    <complexType name="transactionType">
        <element name="Lender" type="t:address"/>
        <element name="Borrower" type="t:address"/>
        <element ref="note" minOccurs="0"/>
        <element name="books" type="t:books"/>
        <attribute name="borrowDate" type="date"/>
    </complexType>

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

    <complexType name="address">
        <element name="name" type="string"/>
        <element name="street" type="string"/>
        <element name="city" type="string"/>
        <element name="state" type="string"/>
        <attribute name="phone" type="string"
            use="optional"/>
    </complexType>

    <complexType name="books">
        <element name="book" minOccurs="0" maxOccurs="10">
            <complexType>
                <element name="bookTitle" type="string"/>
                <element name="pubDate" type="date" minOccurs='0'/>
                <element name="replacementValue" type="decimal"/>
                <element name="maxDaysOut">
                    <simpleType base="integer">
                        <maxExclusive value="14"/>
                     </simpleType>
                </element>
                <attribute name="bookID" type="t:catalogID"
                form="qualified"/>
            </complexType>
        </element>
    </complexType>

    <simpleType name="catalogID" base="string">
        <pattern value="d{3}-d{4}-d{3}"/>
    </simpleType>

</schema>

Here's a document that conforms to this schema—note that all locals are unqualified, except the bookID attribute, which is qualified:

<?xml version="1.0"?>
<at:transaction xmlns:at="http://www.starpowder.com/namespace"
    borrowDate="2001-10-15">
    <Lender phone="607.555.2222">
        <name>Doug Glass</name>
        <street>416 Disk Drive</street>
        <city>Medfield</city>
        <state>MA</state>
    </Lender>
    <Borrower phone="310.555.1111">
        <name>Britta Regensburg</name>
        <street>219 Union Drive</street>
        <city>Medfield</city>
        <state>CA</state>
    </Borrower>
    <at:note>Lender wants these back in two weeks!</at:note>
    <at:books>
        <book at:bookID="123-4567-890">
            <bookTitle>Earthquakes for Breakfast</bookTitle>
            <pubDate>2001-10-20</pubDate>
            <replacementValue>15.95</replacementValue>
            <maxDaysOut>14</maxDaysOut>
        </book>
        .
        .
        .
    </at:books>
</at:transaction>

There's plenty more power wrapped up in schemas. For example, you can have one schema inherit functionality from another, much as you would in an object-oriented programming language, and you can restrict the inheritance process, also as you would in an object-oriented programming language. This standard is one that's still evolving—and still expanding. Let's hope that it won't expand past the capabilities of XML processor authors and that we'll see more processors that will support schemas—at least partially—in the near future.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.117.186.92