1. Default Namespace - targetNamespace or XMLSchema? XML Schemas: Best Practices A set of guidelines for designing XML Schemas Created by discussions on xml-dev

2. Library Book BookCatalogue http://www.publishing.org (targetNamespace) element annotation documentation complexType schema sequence http://www.w3.org/2001/XMLSchema string integer Library.xsd This schema is comprised of components from two namespaces. Which namespace should be the default? CardCatalogueEntry

3. Scenario: Library.xsd Reusing BookCatalogue.xsd targetNamespace="http://www.publishing.org" include BookCatalogue.xsd … "ref" the Book element in BookCatalogue Library.xsd BookCatalogue.xsd The BookCatalogue schema must either: - have the same namespace as the Library schema, or - have no namespace. Declare an element "Book" globally so that it can be reused by other schemas, e.g., the Library schema

4. 3 Ways to Design the Library Schema Version 1: Make XMLSchema the default namespace Version 2: Make the targetNamespace the default namespace Version 3: Have no default namespace

5. Version 1: XMLSchema = Default Namespace <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.library.org" xmlns:lib="http://www.library.org" elementFormDefault="qualified"> <element ref="lib:Book" maxOccurs="unbounded"/> Default namespace is XMLSchema Set "lib" to point to the targetNamespace Qualify the reference to Book

6. Observations about Version 1 Advantages: –If your schema is referencing components from multiple namespaces then this approach provides a consistent way of referring to the components (i.e., you always qualify the reference) Disadvantages: –Schemas which have no targetNamespace must be designed so that the XML Schema components (element, complexType, sequence, etc) are qualified. If you adopt this approach to designing your schemas then in some of your schemas you will qualify the XML Schema components and in other schemas you won't qualify the XML Schema components. Changing from one way of designing your schemas to another way can be confusing.

7. Version 2: targetNamespace = Default Namespace <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.library.org" xmlns="http://www.library.org" elementFormDefault="qualified"> <xsd:element ref="Book" maxOccurs="unbounded"/> Default namespace is targetNamespace Book is in the default namespace (thus, no namespace qualifier required) Set "xsd" to point to the XMLSchema namespace Qualify the XMLSchema components (schema, include, element, complexType, sequence)

8. Observations about Version 2 Advantages: –Schemas which have no targetNamespace must be designed so that the XML Schema components (element, complexType, sequence, etc) are qualified. This approach will work whether your schema has a targetNamespace or not. Thus, with this approach you have a consistent approach to designing your schemas - always namespace-qualify the XML Schema components. Disadvantages: –If your schema is referencing components from multiple namespaces then for some references you will namespace-qualify the reference, whereas other times you will not (i.e., when you are referencing components in the targetNamespace). This variable use of namespace qualifiers in referencing components can be confusing.

9. Version 3: No Default Namespace <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.library.org" xmlns:lib="http://www.library.org" elementFormDefault="qualified"> <xsd:element ref="lib:Book" maxOccurs="unbounded"/> Qualify the XMLSchema components (schema, include, element, complexType, sequence) Set "xsd" to point to the XMLSchema namespace Set "lib" to point to the targetNamespace Qualify the reference to Book

10. Observations about Version 3 Advantages: –If your schema is referencing components from multiple namespaces then this approach provides a consistent way of referring to the components (i.e., you always qualify the reference) –Schemas which have no targetNamespace must be designed so that the XML Schema components (element, complexType, sequence, etc) are qualified. This approach will work whether your schema has a targetNamespace or not. Thus, with this approach you have a consistent approach to designing your schemas - always namespace-qualify the XML Schema components. Disadvantages: –Very cluttered: being very explicit by namespace qualifying everything can also be very annoying when reading the schema. Do Labs1, 2

11. Default Namespace Best Practice There is no clear-cut best practice with regards to this issue. In large part it is a matter of personal preference.