According to the spec for locating Schemas
there may or may not be a schema retrievable via the namespace name... User community and/or consumer/provider agreements may establish circumstances in which [trying to retrieve an xsd from the namespace url] is a sensible default strategy
(thanks for being unambiguous, spec!)
and
in case a document author (human or not) created a document with a particular schema in view, and warrants that some or all of the document conforms to that schema, the schemaLocation and noNamespaceSchemaLocation [attributes] are provided.
So basically with specifying just a namespace, your XML "might" be attempted to be validated against an xsd at that location (even if it lacks a schemaLocation
attribute), depending on your "community." If you specify a specific schemaLocation
, then it basically is implying that the xml document "should" be conformant to said xsd, so "please validate it" (as I read it). My guess is that if you don't do a schemaLocation
or noNamespaceSchemaLocation
attribute it just "isn't validated" most of the time (based on the other answers, appears java does it this way).
Another wrinkle here is that typically, with xsd validation in java libraries [ex: spring config xml files], if your XML files specifies a particular schemaLocation
xsd url in an XML file, like xsi:schemaLocation="http://somewhere http://somewhere/something.xsd"
typically within one of your dependency jars it will contain a copy of that xsd file, in its resources section, and spring has a "mapping" capability saying to treat that xsd file as if it maps to the url http://somewhere/something.xsd
(so you never end up going to web and downloading the file, it just exists locally). See also https://mcmap.net/q/107495/-how-to-validate-an-xml-file-against-an-xsd-file for slightly more info.