22.6. Additional capabilities We'll now describe some additional functions briefly. We'll try to provide just enough detail to allow you to decide whether to investigate them further. 22.6.1 Locally-scoped elements Element-type names in a schema are normally global; any element type can be referenced in any other element type's content model. So if you define title you can use it in chapters, sections and anywhere else you see fit. Once you have defined your schema, authors can use the title element in each of the contexts that you have specified. In each of those contexts the element type is exactly the same: it has the same name, attributes and allowed content. XSDL has a facility that allows you to say that titles in one context should have a different attribute set and content model from titles in another – even if they are in the same namespace! In effect, you can declare two element types with the same name. The name is bound to a different element-type definition in each context. You can do this by declaring an element type within the declaration for another element type. Example 22-14 shows two different title element types declared within the same schema. They each use a different user-derived datatype. Example 22-14. Two locally-scoped title declarations <xsd:element name="book"><xsd:complexType> <xsd:sequence> <xsd:element name="title"><xsd:complexType> <xsd:attribute name="booktitle" use="required" type="xsd:string"/> <xsd:attribute name="ISBN" use="required" type="myns:ISBNFormat"/> </xsd:complexType></xsd:element> <xsd:element ref="myns:chapter"/> </xsd:sequence> </xsd:complexType></xsd:element> <xsd:element name="employee"><xsd:complexType> <xsd:sequence> <xsd:element name="empId"/> <xsd:element name="title"><xsd:complexType> <xsd:sequence> <xsd:element ref="myns:jobtitle"/> <xsd:element ref="myns:company"/> </xsd:sequence> </xsd:complexType></xsd:element> </xsd:sequence> </xsd:complexType></xsd:element>
In documents conforming to this schema, a title element within a book element must conform to the title element declared within the book element declaration, complete with the required ISBN and booktitle attribute values. A title element within an employee element, however, must conform to the title element declared inside the example's employee element declaration. 22.6.2 Type derivation Type derivation is the creation of a new type as a variation of an existing one (or a combination of several existing ones). This is much like the way object-oriented classes inherit from other classes. The derived type will have a content model that is an extension of the base type's. We discussed derivation of simple types in 21.2, "Defining user-derived datatypes", on page 451. In Example 22-15 we see the derivation of a complex type, internationalAddress. It adds a new child element, called countryCode, to the address type we defined in Example 22-3. Example 22-15. One type extends another <xsd:complexType name="internationalAddr"> <xsd:complexContent> <xsd:extension base="myns:address"> <xsd:sequence> <xsd:element ref="myns:countryCode"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType>
With this definition, an internationalAddr is just like an address, but after specifying the details of the address you must also specify a countryCode. You can also derive a type by restriction. That means that you add constraints, such as making an attribute or subelement required when it was previously optional. This is very similar to the equivalent concept for datatypes. 22.6.3 Identity constraints There could be several elements in a document that logically represent a set. For example, records of the employees in a company might be represented as elements in an XML document. Each element in a set must have a unique name or key that distinguishes it from all other elements in the set. For example, the employee records key could be an empid attribute or sub-element. These identity constraints can get even more complicated: we might wish to declare that there must be no two customers with the same first name, last name, and address. XSDL has sophisticated features for defining unique keys and the means of referencing them. It uses XPath for this purpose. For instance you could define the list of customers with one XPath expression and use a second to describe how each member of the set is unique.[4] [4] The discussion in 18.6.7, "Keys", on page 410 gives an idea of the problem and the approach to solving it. | 
