Versioning XML schemas when working with Marklogic

Question

I've read elsewhere that using version strings into the URLs of XML schemas is generally poor practice - for reasons which I understand.

I wonder if this mantra still applies when using a Marklogic DB? My reason being that namespaces and stored XML objects seem very closely linked in Marklogic. The generally recommended approach of storing the version in the XML content seems potentially less useful in this scenario, where you want the DB engine to understand which XSD schema version to use. That suggests to me that contrary to popular wisdom, version strings in the namespace may be a better way to go.

The current revision of our XSD has no version in it, but we will also need to create an enhanced version a few months down the line once we have the existing XML documents imported and working

Edit - if it wasn't obvious, I'm new to Marklogic!

Answer 1

Another way to account for versioning is to use xsi:schemaLocation to say which version of the schema is used by way of the physical location.

Schemas Database:

/schemas/versions/1.0/A.xsd
/schemas/versions/2.0/A.xsd

xsi:schemaLocation="http://www.example.com/schemas/A /schemas/versions/1.0/A.xsd"

and

xsi:schemaLocation="http://www.example.com/schemas/A /schemas/versions/2.0/A.xsd"

In this way, MarkLogic will use the xsd defined in the schemaLocation for indexing and validation, for example.

=========================================================
EDIT: To expand on Mary's comment , the above example is based on the schemas database and also shows full paths. I did not state that. But as far as the schemaLocation being a full path, in some circumstances, you also may only need to import one schema.

Take this example of schemas released as a package:

/schemas/versions/3.0/A.xsd
/schemas/versions/3.0/common/something.xsd
/schemas/versions/3.0/common/something-else.xsd

Imagine that A.xsd has in import statement for ./common/something.xsd
and something.xsd has an import statement for ./something-else.xsd

In this situation, one could get away with just the schemaLocation defined for /schemas/versions/3.0/A.xsd as MarkLogic will import the other two relative to the schema imported.

=========================================================
EDIT 2: An additional question has been asked.. When using SchemaLocation, how in MarkLogic can you tell WHICH schema is being used. The answer is the sc:xxxx functions. The most basic is xs:schema. Among other nifty things, it will tell you the schema and the location of that schema as it resolves it. The function used can be used on any element. I am simply using the document itself in the following examples:

The schemas loaded into the schemas database with a target namespace of http://my/A/Namespace:

/schemas/v3/A.xsd
/schemas/v4/A.xsd

Example where the schemaLocation is set to version 4:

<document
xmlns="http://my/A/Namespace"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://my/A/Namespace /schemas/v4/A.xsd"
>
<something>Bla Bla</something>
</document>/sc:schema()

Result: [164, , http://my/A/Namespace at /schemas/v4/A.xsd ok]

Example where the schemaLocation is set to version 3:

<document
xmlns="http://my/A/Namespace"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://my/A/Namespace /schemas/v3/A.xsd"
>
<something>Bla Bla</something>
</document>/sc:schema()

Result: [164, , http://my/A/Namespace at /schemas/v3/A.xsd ok]

Example where the schemaLocation is NOT SET:

<document
xmlns="http://my/A/Namespace"
>
<something>Bla Bla</something>
</document>/sc:schema()

Result: [164, , http://my/A/Namespace at /schemas/v3/A.xsd ok] In this Case, MarkLogic made the choice...

Example where the schemaLocation is set to a version that does not exist:

<document
xmlns="http://my/A/Namespace"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://my/A/Namespace /schemas/v9999/A.xsd"
>
<something>Bla Bla</something>
</document>/sc:schema()

Result: [108, , http://my/A/Namespace at dummy ok]

In this case, MarkLogic finds you very naughty and refuses to make any assumptions.. If you declare a schemLocation and then there is no xsd at that location, MarkLogic will NOT fall back to finding one on its own.. Plus, as it finds your actions a bit silly, it responds with calling you a dummy.. Well.. There is probably a more technical reason for the word dummy, but I like my description.