790 likes | 968 Views
… more on XML Schemas. Name Conflicts. Whereas DTDs required every element to have a unique name, XML Schemas enable you to use the same name in multiple places . Where can the same name be used, and where will there be a name conflict? Here are the things to remember:
E N D
Name Conflicts • Whereas DTDs required every element to have a unique name, XML Schemas enable you to use the same name in multiple places. • Where can the same name be used, and where will there be a name conflict? Here are the things to remember: • Type definitions (complexType and simpleType) are placed in one symbol space. Element declarations are placed in a second symbol space and attribute declarations are placed in a third symbol space. • Hence, you can have a type and an element and an attribute all with the same name! • Each type definition creates a new symbol space
What's Legal? • Legal • Element, attribute, type (complex or simple) with the same name • Same name in different Symbol Spaces* • Same name in different namespaces • Illegal • Same name and same Symbol Space but different type* • Legal • Same name and same Symbol Space and same type • Note: (*) there are exceptions due to (un)qualified locals.
<xsd:element name="foo"> <xsd:complexType> <xsd:sequence> <xsd:element name="bar" type="xsd:string"/> ... <xsd:element name="bar" type="xsd:string"/> </xsd:sequence> </xsd:complexType </xsd:element> Same name, type, Symbol Space --> Legal <xsd:element name="foo"> <xsd:complexType> <xsd:sequence> <xsd:element name="bar" type="xsd:string"/> ... <xsd:element name="bar" type="xsd:integer"/> </xsd:sequence> </xsd:complexType </xsd:element> Same name, Symbol Space, different type --> Illegal
Global element symbol space <xsd:element name="BookOnCars"> <xsd:complexType> <xsd:sequence> <xsd:element name="Chapter"> <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Section" > <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Title" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:complexType name="Title"> <xsd:sequence> <xsd:element name="CarManufacturer" type="xsd:string"/> <xsd:element name="Year" type="year"/> </xsd:sequence> </xsd:complexType> <xsd:element name="Title" type="xsd:string"/> <xsd:attribute name="Title" type="xsd:string"/> BookOnCars Title Global attribute symbol space Title Global type symbol space Title ScopeTest.xsd (see example 22)
<xsd:element name="BookOnCars"> <xsd:complexType> <xsd:sequence> <xsd:element name="Chapter"> <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Section"> <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Title" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:complexType name="Title"> <xsd:sequence> <xsd:element name="CarManufacturer" type="xsd:string"/> <xsd:element name="Year" type="year"/> </xsd:sequence> </xsd:complexType> <xsd:element name="Title" type="xsd:string"/> <xsd:attribute name="Title" type="xsd:string"/> anonymous symbol space Chapter Title anonymous symbol space Title Section anonymous symbol space Title Title symbol space ScopeTest.xsd (see example 22) CarManufacturer Year
But, but, but, ... • what does this all mean in terms of the namespace that the schema document is defining??? • i.e., the different Symbol Spaces are allowing multiple items with the same name. Is this going to result in a lot of name collisions in the namespace?
CarBooks Namespace? BookOnCars Section Chapter Title Name collisions!!! Title Title Title Title
Global/Local Elements and Namespaces • Only global elements are in the namespace! • Local elements are associated with the global elements. • In our example, the only elements in the namespace are BookOnCars and Title (the globally-declared Title element) • BookOnCars has two local elements associated with it - Chapter and Title. • Chapter has two elements associated with it - Title and Section • Section has one element associated with it - Title
CarBooks Namespace [1] BookOnCars Title [1] Later we will see that the namespace also contains the global types and attributes.
Same Situation with Attributes • Attributes in an XML document are in the same situation as the schema local elements • There can be many attributes with the same name in an XML document; • Attributes are associated with elements which are in the namespace. (See next slide for example)
<?xml version="1.0"?> <Book xmlns="http://www.publishing.org/namespaces/Book"> <Chapter title="Intro to Photography"> <Section title="35mm Cameras"> <Body title="Using the Camera"> The secret to using a 35mm camera is … </Body> </Section> </Chapter> </Book> Default namespace declaration Notice that there are multiple title attributes. If they were all in the namespace then there would be a 3-way name collision. Book Namespace The namespace does not include the attributes. [ On the other hand, one could argue that the attributes are in the namespace by virtue of the fact that they are associated with elements which are in the namespace. ] Book Chapter Section Body
But, but, but, ... • In the instance documents we have been qualifying all elements, thus indicating that they are all in the namespace: <?xml version="1.0"?> <BookCatalogue xmlns =" http://www.publishing.org" ...> <Book> <Title>My Life and Times</Title> <Author>Paul McCartney</Author> <Date>July, 1998</Date> <ISBN>94303-12021-43892</ISBN> <Publisher>McMillin Publishing</Publisher> </Book> ... </BookCatalogue> Default name- space declaration asserts that all these elements are in the Publishing name- space.
Unqualified Local Elements - How? • Local elements are not really in targetNamespace (rather, they are in it, but only by association with a global element which is in it). So how can we indicate to instance document creators that they should only qualify the global elements? • Answer: • elementFormDefault="unqualified“ // in xsd:schema • Notes: • Global elements/attributes names must be qualified • Whether a specific local element/attribute name is qualified or not is determined by schema designers by using form/elementFormDefault/attributeFormDefault
elementFormDefault • In all of our examples thus far we have set the value of this schema attribute to "qualified". The "qualified" value means that in an instance document all element instancesmust be qualified. • Alternatively, you can assign elementFormDefault the value "unqualified". The "unqualified" value means that in an instance document all local element instances must not be qualified.
<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.publishing.org" xmlns="http://www.publishing.org" elementFormDefault="unqualified"> <xsd:element name="BookCatalogue"> <xsd:complexType> <xsd:sequence> <xsd:element name="Book" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Author" type="xsd:string"/> <xsd:element name="Date" type="xsd:string"/> <xsd:element name="ISBN" type="xsd:string“ form=“qualified” /> <xsd:element name="Publisher" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> Notice that there is only one global element in the schema (see example 23)
<?xml version="1.0"?> <b:BookCataloguexmlns:b="http://www.publishing.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.publishing.org BookCatalogue.xsd"> <Book> <Title>My Life and Times</Title> <Author>Paul McCartney</Author> <Date>1998</Date> <b:ISBN>94303-12021-43892</b:ISBN> <Publisher>McMillin Publishing</Publisher> </Book> <Book> <Title>Illusions The Adventures of a Reluctant Messiah</Title> <Author>Richard Bach</Author> <Date>1977</Date> <b:ISBN>0-440-34319-4</b:ISBN> <Publisher>Dell Publishing Co.</Publisher> </Book> <Book> <Title>The First and Last Freedom</Title> <Author>J. Krishnamurti</Author> <Date>1954</Date> <b:ISBN>0-06-064831-7</b:ISBN> <Publisher>Harper & Row</Publisher> </Book> </b:BookCatalogue> Now we don’t use a default namespace declaration, and we qualify only the global element - BookCatalogue. (see example 19)
What’s Validated? • In the previous example, do the local, unqualified elements - Book, Title, Author, Date, ISBN, Publisher - get validated? Yes! Everything is validated just as before, when we used elementFormDefault="qualified"
Use qualified or unqualified? • Case 1: elementFormDefault="unqualified" and only the global elements are qualified • Pro: hides namespace complexity in the schema • Con: if the schema is modified by making local declarations global then all instance documents are impacted; the user needs to keep track of which elements are global versus which elements are local. • Case 2: element elementFormDefault="qualified" and thus all elements are qualified • Pro: if the schema is modified by making local declarations global then the instance documents are not impacted; the user doesn’t need to keep track of which elements are global and which elements are local. • Con: exposes namespace complexity to the instance documents: Users needs to care about which elements are both global and local in the target namespace.
Examples • <xsd:schema … elementFormDefault="unqualified" > • <xsd:element name="title" type="xsd:int"/> • <xsd:element name="book"> • <xsd:complexType><xsd:choice> • <xsd:element name="title" type="xsd:string" form="qualified"/> • <xsd:element ref="title"/> • <xsd:element name="title" type="xsd:long"/> • </xsd:choice></xsd:complexType></xsd:element> • </xsd:schema> Notes: 1. form attr can override elementFormDefault attr 2. 5 and 7 are consistent (two locals with the same names (title) but distinct targetNamespaces due to form=“qualified”) 3. 6 and 7 are consistent (different target namespaces): 4. 5 and 6 are inconsistent (one local, one global but same targetNamespace dueto form=“qualified” (but is consistent if 5 has type='xsd:int' ).
Type Substitutability (Polymorphism) • As we saw earlier, substitutionGroup gives us "element substitutability", i.e., the ability to substitute one element for another. Now we will see how to achieve "type substitutability", i.e., the ability to substitute an element’s content model with another content model. • Here’s how type substitutability works: A base type can be substituted by any derived type. • Example. Suppose that the Book type is derived from Publication. If we declare an element, Listing, to be of type Publication (the base type) then in the instance document Listing's content can be either a Publication or a Book (since Book is a Publication).
<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.publishing.org" xmlns="http://www.publishing.org" elementFormDefault="unqualified"> <xsd:complexType name="Publication"> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Author" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="Date" type="xsd:year"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Book"> <xsd:complexContent> <xsd:extension base="Publication"> <xsd:sequence> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name="Publisher" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="Catalogue"> <xsd:complexType> <xsd:sequence> <xsd:element name="Listing" minOccurs="0" maxOccurs="unbounded" type="Publication"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> Note this Publication is the base type Book extends Publication Listing is of type Publication (the base type) (see example 24)
<?xml version="1.0"?> <cat:Catalogue xmlns:cat ="http://www.publishing.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.publishing.org BookCatalogue.xsd"> <Listing> <Title>Staying Young Forever</Title> <Author>Karin Granstrom Jordan, M.D.</Author> <Date>December, 1999</Date> </ Listing> < Listing xsi:type="cat:Book"> <Title>Illusions The Adventures of a Reluctant Messiah</Title> <Author>Richard Bach</Author> <Date>1977</Date> <ISBN>0-440-34319-4</ISBN> <Publisher>Dell Publishing Co.</Publisher> </ Listing> < Listing xsi:type="cat:Book"> <Title>The First and Last Freedom</Title> <Author>J. Krishnamurti</Author> <Date>1954</Date> <ISBN>0-06-064831-7</ISBN> <Publisher>Harper & Row</Publisher> </ Listing> </cat:Catalogue> This Listing’s content model is the Publication type This Listing’s content model is the Book type This Listing’s content model is the Book type BookCatalogue.xml (see example 24)
<Listing xsi:type="cat:Book"> <Title>Illusions The Adventures of a Reluctant Messiah</Title> <Author>Richard Bach</Author> <Date>1977</Date> <ISBN>0-440-34319-4</ISBN> <Publisher>Dell Publishing Co.</Publisher> </Listing> "The Listing element is declared to be of type Publication. Book is derived from Publication. Therefore, Book is a Publication. Thus, the content of Listing can be a Book. However, to indicate that the content is not the source type, but rather a derived type, we need to specify the derived type that is being used. The attribute 'type' comes from the XML Schema Instance (xsi) namespace." Note in the schema that the Book type is a global type definition. By qualifying Book (cat:Book) we are asserting that the Book type comes from the catalogue namespace.
Why is xsi:type Needed? • Why, in an instance document, do we need to indicate the derived type being used? Couldn’t the schema validator figure out which type was being used? • Answer: • Easier to implement a schema validator • Good practice • c.f: In OO Language like Java, a run time object also contain its actual type information.
Catalogue Namespace T = Type E = Element Publication (T) Book (T) Catalogue (E) A namespace consists of all of the global stuff in the schema - global elements, attributes and types!
Summary of the Contents of the Namespace that a Schema Creates • What is in the namespace that a schema creates? • The namespace is comprised of only the global stuff: • Global elements • Global attributes • Global complexTypes/SimpleTypes • Global AttributeGroup/Group Do Lab 13
block Attribute • You may add an attribute, block, to either an element or a complexType definition. • If you add a block attribute to an element then the content model of that element may not be replaced by a derived type • If you add a block attribute to a complexType then that complexType’s content model may not be replaced by a derived type in any element which is declared to be of that complexType.
<xsd:complexType name="Publication"> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Author" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="Date" type="xsd:year"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Book"> <xsd:complexContent> <xsd:extension base="Publication"> <xsd:sequence> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name="Publisher" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="Catalogue"> <xsd:complexType> <xsd:sequence> <xsd:element name="Listing" minOccurs="0" maxOccurs="unbounded" type="Publication"/> </xsd:sequence> </xsd:complexType> </xsd:element> Schema: The Publication type, and types derived from Publication may be substituted for the content model of Listing, e.g., Book may be used. <Listing xsi:type="cat:Book"> <Title>Illusions The Adventures of a Reluctant Messiah</Title> <Author>Richard Bach</Author> <Date>1977</Date> <ISBN>0-440-34319-4</ISBN> <Publisher>Dell Publishing Co.</Publisher> </Listing> Instance doc:
<xsd:complexType name="Publication"> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Author" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="Date" type="xsd:year"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Book"> <xsd:complexContent> <xsd:extension base="Publication"> <xsd:sequence> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name="Publisher" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="Catalogue"> <xsd:complexType> <xsd:sequence> <xsd:element name="Listing" minOccurs="0" maxOccurs="unbounded" type="Publication" block="#all"/> </xsd:sequence> </xsd:complexType> </xsd:element> Schema: This prohibits the use of types derived from Publication from being used as the content model of Listing, i.e.., this is not allowed <Listing xsi:type="cat:Book"> <Title>Illusions The Adventures of a Reluctant Messiah</Title> <Author>Richard Bach</Author> <Date>1977</Date> <ISBN>0-440-34319-4</ISBN> <Publisher>Dell Publishing Co.</Publisher> </Listing> Instance doc:
<xsd:complexType name="Publication" block="#all"> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Author" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="Date" type="xsd:year"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Book"> <xsd:complexContent> <xsd:extension base="Publication"> <xsd:sequence> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name="Publisher" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="Catalogue"> <xsd:complexType> <xsd:sequence> <xsd:element name="Listing" minOccurs="0" maxOccurs="unbounded" type="Publication"/> </xsd:sequence> </xsd:complexType> </xsd:element> Schema: This prohibits Publication’s content model from being replaced by a derived type in any element declared to be of Publication type, such as Listing, i.e., this is not allowed <Listing xsi:type="cat:Book"> <Title>Illusions The Adventures of a Reluctant Messiah</Title> <Author>Richard Bach</Author> <Date>1977</Date> <ISBN>0-440-34319-4</ISBN> <Publisher>Dell Publishing Co.</Publisher> </Listing> Instance doc:
Block Attribute • block="extension" • Prohibits you from substituting a derived-by-extension type for an element's content • block="restriction" • Prohibits you from substituting a derived-by-restriction type for an element's content • block="#all" • Prohibits you from substituting any derived type for an element's content • block="substitution" • This prohibits element substitution • possible values: (#all | listOf(extension |restriction | substituion)) // for element/@block; no 'substitution' for complexType
Abstract Elements • You can declare an element to be abstract • Example.<xsd:element name="Publication" type="PublicationType" abstract="true"/> • An abstract element is a template/placeholder element: • If an element is declared abstract then in an XML instance document that element may not appear. • Example. The <Publication> element shown above may not appear in an instance document. • However, elements that are members of a substitutionGroup whose head is an abstract element may appear in its place.
<xsd:complexType name="PublicationType"> <xsd:sequence> <xsd:element name="Title" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="Author" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="Date" type="xsd:year"/> </xsd:sequence> </xsd:complexType> <xsd:element name="Publication" type="PublicationType" abstract="true"/> <xsd:element name="Book" substitutionGroup="Publication"> <xsd:complexType> <xsd:complexContent> <xsd:extension base="PublicationType"> <xsd:sequence> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name="Publisher" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="Magazine" substitutionGroup="Publication"> <xsd:complexType> <xsd:complexContent> <xsd:restriction base="PublicationType"> <xsd:sequence> <xsd:element name="Title" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="Author" type="xsd:string" minOccurs="0" maxOccurs="0"/> <xsd:element name="Date" type="xsd:year"/> </xsd:sequence> </xsd:restriction> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="Catalogue"> <xsd:complexType> <xsd:sequence> <xsd:element ref="Publication" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> The Book and Magazine elements are substitutionGroup'ed to the Publication element. Since the Publication element is abstract, only substitutionGroup’ed elements can appear as children of Catalogue. (see example 25)
An XML Instance Document Conforming to Catalogue.xsd <?xml version="1.0"?> <Catalogue xmlns="http://www.publishing.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.publishing.org Catalogue.xsd"> <Magazine> <Title>Natural Health</Title> <Date>1999</Date> </Magazine> <Book> <Title>Illusions The Adventures of a Reluctant Messiah</Title> <Author>Richard Bach</Author> <Date>1977</Date> <ISBN>0-440-34319-4</ISBN> <Publisher>Dell Publishing Co.</Publisher> </Book> <Book> <Title>The First and Last Freedom</Title> <Author>J. Krishnamurti</Author> <Date>1954</Date> <ISBN>0-06-064831-7</ISBN> <Publisher>Harper & Row</Publisher> </Book> </Catalogue> (see example 25)
Abstract complexType • You can declare a complexType to be abstract • Example.<xsd:complexType name="PublicationType" abstract="true"/> • An abstract complexType is a template/placeholder type: • If an element is declared to be a type that is abstract then in an XML instance document the content model of that element may not be that of the abstract type. • Example. An element declared to be of type PublicationType (shown above) may not have that type’s content model. • However, complexType’s that are derived from the abstract type may substitute for the abstract type.
Note that PublicationType is declared abstract. <xsd:complexType name="PublicationType" abstract="true"> <xsd:sequence> <xsd:element name="Title" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="Author" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="Date" type="xsd:year"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Book"> <xsd:complexContent> <xsd:extension base="PublicationType"> <xsd:sequence> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name="Publisher" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="SingleAuthorPublication"> <xsd:complexContent> <xsd:restriction base="PublicationType"> <xsd:sequence> <xsd:element name="Title" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="Author" type="xsd:string"/> <xsd:element name="Date" type="xsd:year"/> </xsd:sequence> </xsd:restriction> </xsd:complexContent> </xsd:complexType> <xsd:element name="BookCatalogue"> <xsd:complexType> <xsd:sequence> <xsd:element name="Book" minOccurs="0" maxOccurs="unbounded" type="PublicationType"/> </xsd:sequence> </xsd:complexType> </xsd:element> Book derives from PublicationType. By default abstract="false". Thus, this type can substitute for the PublicationType. (see example 26)
<?xml version="1.0"?> <BookCatalogue xmlns="http://www.publishing.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.publishing.org BookCatalogue.xsd"> <Book xsi:type="Book"> <Title>My Life and Times</Title> <Author>Paul McCartney</Author> <Date>1998</Date> <ISBN>94303-12021-43892</ISBN> <Publisher>McMillin Publishing</Publisher> </Book> <Book xsi:type="SingleAuthorPublication"> <Title>FooManchu</Title> <Author>Don Knox</Author><Date>1951</Date> </Book> <Book xsi:type="PublicationType"> // error! <Title>FooManchu</Title> <Author>Don Knox</Author><Date>1951</Date> </Book> <Book> // error! <Title>FooManchu</Title> <Author>Don Knox</Author><Date>1951</Date> </Book> </BookCatalogue> The content model of each <Book> element must be from a type that derives from PublicationType. In the schema there are two such types - Book and SingleAuthorPublication.
Review of Abstract Elements and Abstract complexTypes • If you declare an element to be abstract • > Use element substitution for the abstract element (as provided by substitutionGroup) name/type • If you declare a complexType to be abstract • > Use type substitution for the abstract type (as provided by type derivation) • element name not changed!! • use xsi:type to refer to actual type • use the content model of the actual type Do Lab 14
Redefining a Type from the Included Schema • The <redefine> element does the same thing as an <include> element (i.e., it allows you to access components in other schemas, provided they have the same namespace), plus it enables you to redefine one or more components (simpleType, complexType, attributeGroup, or group)
<xsd:complexType name="CardCatalogueEntry"> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Author" type="xsd:string"/> <xsd:element name="Date" type="xsd:string"/> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name="Publisher" type="xsd:string"/> </xsd:sequence> </xsd:complexType> LibraryBookCatalogue.xsd (snippet, see example27) <xsd:redefine schemaLocation="LibraryBookCatalogue.xsd"> <xsd:complexType name="CardCatalogueEntry"> <xsd:complexContent> <xsd:extension base="CardCatalogueEntry"> <xsd:sequence> <xsd:element name="Review" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:redefine> Library.xsd (snippet , see example27)
<xsd:redefine schemaLocation="LibraryBookCatalogue.xsd"> <xsd:complexType name="CardCatalogueEntry"> <xsd:complexContent> <xsd:extension base="CardCatalogueEntry"> <xsd:sequence> <xsd:element name="Review" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:redefine> Library.xsd (snippet , see example27) This <redefine> element does two things: - it includes the components from LibraryBookCatalogue.xsd - it redefines CardCatalogueEntry (in LibraryBookCatalogue.xsd) by extending it with a new element (Review).
Note about <redefine> • When a schema redefines a component then it's as though the old version of the component no longer exists. Any reference to the redefined component (either in the included schema or in the including schema) is to this new version.
<xsd:element name="BookCatalogue"> <xsd:complexType> <xsd:sequence> <xsd:element name="Book" minOccurs="0" maxOccurs="unbounded" type="CardCatalogueEntry"/> </xsd:sequence> </xsd:complexType> </xsd:element> LibraryBookCatalogue.xsd (snippet , see example27) Because CardCatalogueEntry has been redefined, Book's content now also includes Review.
<redefine> Element <redefine schemaLocation="URL to schema document"> [simpleType or complexType or attributeGroup or group]* </redefine> “The <redefine> element can redefine zero or more components in the referenced schema.”
Redefining a Schema with no targetNamespace • External components from schemas that have no namespace can also be redefined. • The redefined components become part of the redefining schema's namespace. • Thus, a schema with no namespace may "blend in" with a variety of different schemas and take on each schema's namespace!
<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xsd:complexType name="CardCatalogueEntry"> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Author" type="xsd:string"/> <xsd:element name="Date" type="xsd:string"/> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name="Publisher" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:schema> BookCatalogue.xsd (see example28) Note that there is no targetNamespace!
<xsd:redefine schemaLocation="BookCatalogue.xsd"> <xsd:complexType name="CardCatalogueEntry"> <xsd:complexContent> <xsd:extension base="CardCatalogueEntry"> <xsd:sequence> <xsd:element name="Review" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:redefine> Library.xsd (snippet , see example28) As soon as we redefine BookCatalogue.xsd it takes on the library namespace.
Note about redefining a schema with no targetNamespace • If the components in the schema with no targetNamespace ref one another then the <include>ing schema must be designed so that the targetNamespace is the default namespace! <xsd:complexType name="CardCatalogueEntry"> <xsd:sequence> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Author" type="xsd:string"/> <xsd:element name="Date" type="xsd:string"/> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name="Publisher" type="xsd:string"/> </xsd:sequence> <xsd:element name="BookCatalogue" type="CardCatalogueEntry"/> When this schema takes on a namespace then type="CardCatalogueEntry" will be referring to the default namespace. If the default namespace is not the targetNamespace then this reference will break!
Version Management • The schema element has an optional attribute, version, which you may use to indicate the version of your schema (for private version documentation of the schema) <?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.publishing.org" xmlns="http://www.publishing.org" elementFormDefault="qualified" version="1.0"> ... </xsd:schema>