I need to take a look at the schema ident etc to check as your profile seems similar to some of the ones we use but won't have time until later this week. I can't really see a problem with the resolver doing things in order that they are loaded unless the standard namespaces (eg gmd) are being remapped but that doesn't seem to be the case in your profile (and IMO probably wouldn't be a good profile design choice anyway!).
As regards using the local xsds for validation, it's a performance and reliability choice - it also means that the metadata is validated against the schemas actually being used in the editor and finally it is also the way in which GN used to do validation. In any case, if you want to validate against remote schemas you can disable that mapping in the oasis catalog or even provide a map to somewhere else if you want.
Hope I haven't misunderstood what you're intending here - I'll get back in touch later this week - would also like to look at your profile in more detail too (can you send it to me?).
Cheers and thanks,
Simon
________________________________________
From: Jose Garcia [jose.garcia@anonymised.com]
Sent: Monday, 2 July 2012 10:01 PM
To: Pigot, Simon (CMAR, Hobart)
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Schema plugins (oasis catalog files)
Hi Simon
Adding the dependency to iso19139 schema doesn't work, but noticed that in my computer schemas are loaded in alphabetical order and for some reason in the test server are loaded in other order.
I know it's not the solution, but added highlighted line in SchemaManager constructor to verify if order matters:
String saSchemas = new File(this.schemaPluginsDir).list();
Arrays.sort(saSchemas);
And works ok now, so the order used to load profiles seem relevant.
Can be that XmlResolver just searches in order for gmd.xsd in the oasis catalog files and don't check the real schema to use (XmlResolver indeed seem not using schema name)? or maybe my schema-ident.xml provided previously is not ok?
Another question is why seem using local xsd files? No way to use the remote files defined in schemaLocation?
Thanks and regards,
Jose García
On Mon, Jul 2, 2012 at 1:29 PM, Jose Garcia <jose.garcia@anonymised.com<mailto:jose.garcia@anonymised.com>> wrote:
Hi Simon
I have this:
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://geonetwork-opensource.org/schemas/schema-ident" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://geonetwork-opensource.org/schemas/schema-ident/schema\-ident\.xsd">
<name>iso19139.napec</name>
<id>ab6f3bc0-dde4-11df-8626-001c2346de4c</id>
<version>1.0</version>
<schemaLocation>http://http://www.ec.gc.ca/napec schema.xsd</schemaLocation>
<autodetect xmlns:napec="http://www.ec.gc.ca/napec">
<elements type="search">
<napec:MD_DataIdentification/>
</elements>
</autodetect>
</schema>
The new schema redefines MD_DataIdentification element and the metadata to load has gmd:MD_DataIdentification, the strange stuff is the different behavior in different systems.
Maybe adding a dependency to iso19139 schema solves the order issue, going to try it.
Regards,
Jose García
On Mon, Jul 2, 2012 at 1:18 PM, <Simon.Pigot@anonymised.com<mailto:Simon.Pigot@anonymised.com…192…>> wrote:
Hi Jose,
Seems like you may not be distinguishing your new profile from the base iso19139 - what do you have in the schema-ident.xml file for the new profile?
Cheers,
Simon
________________________________________
From: Jose Garcia [jose.garcia@anonymised.com<mailto:jose.garcia@anonymised.com>]
Sent: Monday, 2 July 2012 8:48 PM
To: Devel geonetwork-devel@lists.sourceforge.net<mailto:geonetwork-devel@anonymised.comsts.sourceforge.net>
Subject: [GeoNetwork-devel] Schema plugins (oasis catalog files)
Hi
I have a schema plugin based on iso19139 and trying to import a standard iso19139 metadata thats has a defined schemaLocation with Validate option checked, I get different results depending on the computer I try:
* Locally I get the metadata imported with no validation errors (thats correct)
* In a test server (using same war) I get metadata validation errors that correspond to the new schema defined. But the metadata is identified as iso19139 properly (not as the new schema plugin).
Supposedly, if a metadata has schemaLocation, should use it, but seem not the case. I think is related to the oasis catalog files.
Also seem these files are tried in order? In the log from my computer I see this:
- Using oasis catalog files
../geonetwork/WEB-INF/oasis-catalog.xml;
../geonetwork/WEB-INF/data/config/schemaplugin-uri-catalog.xml;
../WEB-INF/data/config/schema_plugins/iso19139/oasis-catalog.xml
../geonetwork/WEB-INF/data/config/schema_plugins/iso19139.myprofile/oasis-catalog.xml;
while in the test server:
- Using oasis catalog files
../geonetwork/WEB-INF/oasis-catalog.xml;
../geonetwork/WEB-INF/data/config/schemaplugin-uri-catalog.xml;
../geonetwork/WEB-INF/data/config/schema_plugins/iso19139.myprofile/oasis-catalog.xml;
../WEB-INF/data/config/schema_plugins/iso19139/oasis-catalog.xml
So:
1) Seem some relation in the order of these files are used to select the xsd for metadata validation. But should be selected by schema name, no?
2) Seem also used local xsd for validation even if schemaLocation is defined in metadata. Any reason for this? Seem a bit strange.
Thanks and regards,
Jose García
--
GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net/> for details.
_________________________
Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands
http://GeoCat.net/>
--
GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net/> for details.
_________________________
Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands
http://GeoCat.net/>
--
GeoCat Bridge for ArcGIS allows instant publishing of data and metadata on GeoServer and GeoNetwork. Visit http://geocat.net/> for details.
_________________________
Jose García
GeoCat bv
Veenderweg 13
6721 WD Bennekom
The Netherlands
http://GeoCat.net/>