4

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!

Sofia
  • 771
  • 1
  • 8
  • 22
Rob Walker
  • 190
  • 1
  • 7

2 Answers2

4

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.

David Ennis -CleverLlamas.com
  • 7,560
  • 12
  • 20
  • Thanks for the responses - need to re-read and experiment, but I think I'm getting this. The schemaLocation is providing a path which is resolvable into the ML Schemas d/b, rather than using the URI to locate it. I guess follow on Q - is it possible somewhere for me to see/diagnose which schema is actually being found/resolved - so I be sure when I have it right? – Rob Walker Sep 11 '15 at 05:12
  • I have updated the original answer with a response to your question. This is how you can check for any document which schema is being loaded. In addition, if you use xdmp:validate and there is a failure, the schema location is part of the bazillion lines of error message information. – David Ennis -CleverLlamas.com Sep 11 '15 at 21:53
  • 1
    Great, thanks. I was actually being super-lazy there - with a bit of digging I found a whole manual section on XML schemas. My bad for just posting without looking. Anyhow good news is that manual section and you rposts here have helped me get it straight in my head, many thanks. – Rob Walker Sep 13 '15 at 09:47
  • NO problem.. If the answer matches, please mark it as the accepted answer. This helps keep stackoverflow clean and organized – David Ennis -CleverLlamas.com Sep 13 '15 at 15:10
3

Note that this schema location is the URI of the schema in the Schemas database, not on the web. So make sure you load the schemas into the database at the appropriate URI. It is a good idea to avoid relative URIs for schema locations -- not that they can't work, but because you often end up resolving them relative to something other than what you thought, and if the schema is not resolved at the location you said, MarkLogic will fall back to using whatever schema it can find for that namespace.

mholstege
  • 4,902
  • 11
  • 7