Q:

Versioning XML schemas when working with Marklogic

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! 

A:

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. 

A:

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. 