• Schema provides two facilities for modularity:

  • xs:include - includes a set of definitions/declarations as if they were inlined (cut-n-paste).

  • xs:import - imports a different namespace so you can use its definitions/declarations.

• The 'include' element occurs at the top level.

• Example:

  <xs:include schemaLocation="some-module.xsd"/>
  <xs:include schemaLocation="http://cde.berkeley.edu/schemas/chunk-of-something.xsd"/>

• The target namespace of the included schema must:

  • match the current target namespace (i.e. the targetNamespace attributes have the same value).

  • have no value (e.g. no targetNamespace attribute).

• All top-level elements become part of the current target namespace.

• The 'import' element occurs at the top level.

• Example:

  <xs:import namespace="urn:publicid:IDN+cde.berkeley.edu:schemas:something:us" 
             schemaLocation="something.xsd"/>
  <xs:import namespace="http://www.w3.org/1999/xhtml" 
             schemaLocation="xhtml.xsd"/>

• The 'namespace' attribute specifies what namespace you are attempting to import.

• The 'schemaLocation' attribute is not required, but recommended.

• You still have to define a prefix to refer to definitions/declarations.

• This schema imports a schema for XHTML.

• It then refers to the element declaration for the 'p' element.

• Example:

  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
     targetNamespace="urn:publicid:IDN+cde.berkeley.edu:schemas:examples:snippet:us"
     xmlns:h="http://www.w3.org/1999/xhtml"
  >
  
     <xs:import namespace="http://www.w3.org/1999/xhtml"
                schemaLocation="xhtml.xsd"/>
  
     <xs:element name="snippet">
        <xs:complexType>
           <xs:sequence>
              <xs:element ref="h:p" maxOccurs="unbounded"/>
           </xs:sequence>
        </xs:complexType>
     </xs:element>
  
  </xs:schema>

• Imported schemata can import schemata which import schemata which...

• 

  Figure 1. Figure

• Declarations/Definitions belong to target namespace of where the occur (i.e. the value of the targetNamespace attribute nearest to them).

• You don't have specify where imports of imported schemata are located.

• At minimum you need to import the namespace of all definitions/declarations used.

1. Global declarations require qualified name in the instance.

2. Local declarations are unqualified unless you specifically say otherwise.

3. If your declaration requires a qualified name, the namespace is the value of the 'targetNamespace' of the document where the declaration occurs.

• This should work in all processors:

  • Schema A imports schema B.

  • Schema B imports schema C.

  • Schema A uses a declaration from schema C.

• Example:

  • Schema A: ichain-1.xsd

  • Schema B: ichain-2.xsd

  • Schema C: ichain-3.xsd

  • Instance: ichain.xml

• What happens when your imports have imports?

• Declarations are bound to the target namespace of where they occur.

• Unqualified local element declarations mean no namespace for the element in the instance.

• Example:

  • Base Schema: base.xsd

  • Importing Schema: importer.xsd

  • Conforming Document: importer.xml

• Unqualified local elements have no namespace name.

• So, even though their types are in different namespaces, the elements aren't.

• Example:

  • Type Library: type-library.xsd

  • Document Schema: person-location.xsd

  • Conforming Document: person-location.xml

• If you qualify all your local elements, you may end up with many different namespaces in your instance.

• Having deep schema derivations makes this worse.

• Having five namespaces isn't unrealistic, but this example is silly:

  • Five levels of derivation: level1.xsd level2.xsd level3.xsd level4.xsd level5.xsd

  • Conforming Document: level.xml

Now it is time to switch gears to something completely different but related!

The goals for this lecture and discussion are as follows:

• To provide some kind of mapping to relational database modeling practices.

• To establish the connection to Document Engineering.

• Help in understanding how XML and XML Schema fit into modeling processes.

1. Developing a model involves understanding the domain, context, use, and conflicts to develop some rational model of a domain within some application.

2. Encoding a model is where you translate (1) into effective schemata that can be used to create or check instances and also drive processes.

• A lot of people "cheat" and develop their schema without developing a model:

  • A schema is better than no schema.

  • A carefully thought-out and document schema is better than just a schema.

  • A schema that is designed against a model is best.

• But "cheating" is OK in some contexts:

  • Application specific documents.

  • Ad-hoc documents.

  • Simple narratives or interchange documents.

  • Situations where you need a schema for typing/validation.

• But there are many application domains and standardization efforts where you are better off developing a model first.

• Relational databases aren't any different in that:

  • Models still need to be developed from domain, context, use, etc.

  • Models are encoded in a database's definition language (DDL).

• There is one huge difference:

  Databases are not designed for interchange of information. It almost always is the case that the average user will not see the data via SQL or views. As such, the structure, complexity, and ease at which the information is obtained is the purview of the developer and not the owner or user of the information.

• That is, with XML, there are more observers of the information and its structures.

• Traditional data dictionaries are just a laundry list of "information elements".

• There is usually the following information:

  • name

  • type information (char[20]).

  • human-readable description.

  • constraint information.

• It may look like an XML Schema types but:

  • complex types are aggregates and data dictionaries usually aren't.

  • complex types have content models that describe child occurrence.

  • complex types have both children and attributes.

• Keep this in mind as we proceed.

1. Analyze the context of use.

2. Analyze the business process.

3. Apply patterns to process models.

4. Analyze documents.

5. Analyze document components.

6. Assemble document components.

7. Assemble document models.

8. Implement process and document models.