Según la especificación para localizar esquemas
puede o no haber un esquema recuperable a través del nombre del espacio de nombres ... La comunidad de usuarios y / o los acuerdos de consumidor / proveedor pueden establecer circunstancias en las que [intentar recuperar un xsd de la url del espacio de nombres] es una estrategia sensata predeterminada
(¡Gracias por ser inequívoco, especificación!)
y
en caso de que un autor del documento (humano o no) haya creado un documento con un esquema particular a la vista, y garantiza que parte o la totalidad del documento se ajusta a ese esquema, se proporcionan los atributos de schemaLocation y noNamespaceSchemaLocation.
Básicamente, al especificar solo un espacio de nombres, su "XML" podría intentarse para ser validado contra un xsd en esa ubicación (incluso si carece de un schemaLocation
atributo), dependiendo de su "comunidad". Si especifica un específico schemaLocation
, entonces básicamente implica que el documento xml "debería" ser compatible con dicho xsd, así que "valídelo" (mientras lo leo). Mi conjetura es que si no haces un atributo schemaLocation
o noNamespaceSchemaLocation
simplemente simplemente "no está validado" la mayoría de las veces (según las otras respuestas, parece que Java lo hace de esta manera).
Otra arruga aquí es que, por lo general, con la validación xsd en las bibliotecas de Java [ej .: archivos xml de config de primavera], si sus archivos XML especifican una schemaLocation
url xsd particular en un archivo XML, como xsi:schemaLocation="http://somewhere http://somewhere/something.xsd"
típicamente dentro de uno de sus frascos de dependencia, contendrá una copia de ese archivo xsd, en su sección de recursos, y spring tiene una capacidad de "mapeo" que dice tratar ese archivo xsd como si se asignara a la url http://somewhere/something.xsd
(para que nunca termines yendo a la web y descargando el archivo, solo existe localmente). Consulte también https://stackoverflow.com/a/41225329/32453 para obtener un poco más de información.