1. Home
  2. News & Blogs
  3. Common S1000D Schema Location

News & Blogs

Common S1000D Schema Location

- Monday, 7th July 2025

Are you working with multiple S1000D and S1000D-derived outputs?

If you are then I have no doubt that you are making extensive use of the Oxygen XML frameworks but, at the end of the day, an S1000D Data Module is still just an S1000D Data Module.

Frameworks:

  • S1000D-Standard
  • ATA Spec 1000BR
  • ATA Work Cards
  • GAMA1 POH/AFM
  • S1000D JSS-0251
  • S1000D JSG-0308
  • S1000D Shipdex
  • S1000D AESP

Regardless of which framework you’re working in, the S1000D Data Module (DM) still needs to be validated against the relevant DTD/Schema!

Within Docuneering, we have setup a Common S1000D Schema Location and thought we would share the idea with the S1000D Community in an effort to help others simplify the validation process and avoid some of the simple mistakes we made along the way.

Step 1 - Download the schema files

Download all, or as many of the different S1000D Issues as you need from the official s1000d.org website:

We downloaded ALL of the different S1000D XML Issues and Patches:

(Click image to enlarge)

Docuneering - Common S1000D Schema Location

Common S1000D Schema Location

If you would like a ZIPPED copy of this folder structure, please...

Get in touch

Step 2 - Configure the Oxygen XML framework(s)

From within your Oxygen XML framework, you now need to tell it where to look for the XML catalog.xml file

Select: Options > Preferences...

This will open the Preferences dialog...

(Click image to enlarge)

Docuneering - Oxygen XML - Preferences dialog

Oxygen XML - Preferences dialog

From the lefthand option list, select Document Type Association and in righthand side Document type list, select your framework and click Edit (or simply double click the framework).

Within your framework, select the Catalogs tab...

(Click image to enlarge)

Docuneering - Oxygen XML - Catalogs tab

Oxygen XML - Catalogs tab

While we could use an absolute path in the framework to point to our Common S1000D Schema Location "catalog.xml" file, we also wanted the option to create a portable version of the framework.

(Click image to enlarge)

Docuneering - Oxygen XML - Framework catalog file

Oxygen XML - Framework catalog file

This method allows us to use either the Common S1000D Schema Location or a local version stored in the framework to make it fully portable.

Please Note: We do not have duplicate files stored in the Common S1000D Schema Location and the framework folder. We only use the Common S1000D Schema Location within our frameworks but we wanted a method to "allow us" to share the framework.

Step 3 - Create the XML catalog.xml rewrite rules

*** This is the important bit! ***

The catalog file has historically been used to point to the different DTD/schema file(s) but it also tended to include entities and other associated bits.

With S1000D XML, the catalog "rewrite rule" allows us to simply point to local files but, for it to work correctly (or to even work at all), it is important to use the folder structure as provided.

If you UNZIP the different packages from the s1000d.org website and use the as provided folder structure, all of the relative path information contained within the different files will resolve.

It's created as a self-contained package!

Before we proceed onto the catalog.xml rewrite rules we first need to understand how a DM knows which schema to validate against.

When you open a DM, the @xsi:noNamespaceSchemaLocation contains a URI to the XSD schema file.

(Click image to enlarge)

Docuneering - S1000D XML - Schema URL

S1000D XML - Schema URL

This example S1000D Issue 4.2 DM is pointing to the descript.xsd schema in the S1000D_4-2 folder so we know it's an Issue 4.2 Descriptive doctype.

(Click image to enlarge)

Docuneering - S1000D XML - Schema URL - Descriptive doctype

S1000D XML - Schema URL - Descriptive doctype

You could continue to use this URI method to validate your DM's but it has the following drawbacks:

  • Slower to validate
  • Requires internet access
  • Fails if site is unreachable
  • Could be blocked

It is therefore quicker and more stable to validate against local schema files.

To change the validation to your local files we need to implement some rewrite rules in the catalog.xml file:

(Click image to enlarge)

Docuneering - S1000D XML Schema - Catalog rewrite rules

S1000D XML Schema - Catalog rewrite rules

So ... what are we doing here?

To rewrite the URI to a set of local files we need to define the @systemIdStartString and the @rewritePrefix.

If we focus on the S1000D Issue 4.2 rewrite rule (on line 23 of the previous image) and look at the example DM, it finds a matching @systemIdStartString:

(Click image to enlarge)

Docuneering - S1000D XML Schema - @systemIdStartString Match

S1000D XML Schema - @systemIdStartString Match

So it changes (rewrites) it from:

  • "http://www.s1000d.org/S1000D_4-2/xml_schema_flat/descript.xsd"

To:

  • "4.2/xml_schema_flat/descript.xsd"

This new "rewrite" creates a path which is relative to the location of the catalog.xml file

(Click image to enlarge)

Docuneering - S1000D XML Schema - Catalog.xml relative path

S1000D XML Schema - Catalog.xml relative path

This is why it's important (vital even) to use the as provided folder structure.

The S1000D ZIP file folder structure matches the structure of the @xsi:noNamespaceSchemaLocation URI.

The rewrite rule is simply changing the first part of the URL to use a relative local path and then uses the rest of the URL to find the schema file.

(Click image to enlarge)

Docuneering - S1000D XML Schema - Issue 4.2 descript.xsd relative path

S1000D XML Schema - Issue 4.2 descript.xsd relative path

And that's it ... you are now using local files for fast, stable and uninterrupted S1000D XML validation!

News & Blogs menu

Latest News & Blogs
2025
2024
2023
2022
2021
2020

Want to find out more?

Contact Us