[auscope-geosciml] GA_MappedFeature_GeologicUnit_wfs2.0 instance

Sen, Marcus A. mase at bgs.ac.uk
Thu May 12 12:31:17 EDT 2011

> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-
> geosciml-bounces at lists.arcs.org.au] On Behalf Of
> Bruce.Simons at dpi.vic.gov.au
> Sent: 12 May 2011 04:26

> A. Validation Errors
> Has anyone using XMLSpy without local catalogs been able to validate
> the instance documents?
I have been using oXygen v12 with a catalog to redirect references to schemas.geosciml.org to my local copies as, when I started, the RC2 schemas weren't up on schemas.geosciml.org and I also wanted the option of trying against other versions of the schemas. I've only just noticed today that the RC2 schemas are at http://schemas.geosciml.org/geosciml/3.0/geosciml.xsd etc.! So I've now removed my catalog and tried again. I also tried with an old copy of XML Spy (2008 sp1) which I still have on my machine but haven't used for ages.

(Still using the oXygen default catalog which has local copies of things like DocBook, XML, XHTML etc. I think XML Spy also has a default catalog for similar common standards.)

Brief summary: oXygen still validates the geosciml.xsd schema and the BGS and GA instances, I get the same errors as Bruce with XML Spy.

> 1. A mismatch between the declared namespace and the target namespace
> gives this error:
> File
> GeoSciML\branches\3.0.0_rc2\instances\GA_MappedFeature_GeologicUnit_wfs
> 2.0.xml could not be validated because of an error in XML Schema/DTD
> (see below)
>         Schema at location
> 'http://schemas.geosciml.org/geosciml/3.0/geosciml.xsd' has target
> namespace 'http://xmlns.geosciml.org/GeoSciML/3.0' rather than
> 'http://xmlns.geosciml.org/GeoSciML-Core/3.0'.
>                 Details
>                         schema_reference: Schema at location
> 'http://schemas.geosciml.org/geosciml/3.0/geosciml.xsd' has target
> namespace 'http://xmlns.geosciml.org/GeoSciML/3.0' rather than
> 'http://xmlns.geosciml.org/GeoSciML-Core/3.0'.
> I don't understand how Oxygen ignores this problem (are you sure you
> are not using a local cache?)
I have tried re-reading the XML Schema spec. and although I'm not confident in my reading of this I don't think it is an error for the target namespace not to be the same. Loading the schema document at 'http://schemas.geosciml.org/geosciml/3.0/geosciml.xsd' will give a schema which can be used to validate elements in the 'http://xmlns.geosciml.org/GeoSciML-Core/3.0' namespace. In particular, the part of the spec referred to by XML spy in its error message (http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#schema_reference) doesn't seem to imply this. So I *think* XML Spy is wrong on this. (Note the rules for schemaLocation on import elements do require the target namespace of the referred schema be the same as the namespace attribute but this is not the same as the rules on the xsi:schemaLocation attribute on an instance document element.)

> 2. Changing the namespace to "http://xmlns.geosciml.org/GeoSciML/3.0
> <http://xmlns.geosciml.org/GeoSciML/3.0>
> http://schemas.geosciml.org/geosciml/3.0/geosciml.xsd
> <http://schemas.geosciml.org/geosciml/3.0/geosciml.xsd> " results in
> the following error:
Switching the namespace to http://xmlns.geosciml.org/GeoSciML/3.0 also works in oXygen so, pending any authoritative answer as to the correct behaviour I suggest we do change our instances to this way round as they will at least work in both environments and it is probably less confusing. (Although perhaps it is a bit confusing that we are giving a schemaLocation for a namespace that isn't actually used in the instance document. We have a target namespace http://xmlns.geosciml.org/GeoSciML/3.0 for the wrapper schema document which isn't used for anything.)

> 'sam:SamplingFeatureComplex' is already declared in schema document
> 'http://schemas.opengis.net/sampling/2.0/samplingFeature.xsd'.
>         Error location: schema / element
>         Details
>                 sch-props-correct.2: 'sam:SamplingFeatureComplex' is
> already declared in schema document
> 'http://schemas.opengis.net/sampling/2.0/samplingFeature.xsd'.
> This error varies but always relates to and O&M class. Is this a result
> of importing both http://www.opengis.net/swe/1.0/gml32
> <http://www.opengis.net/swe/1.0/gml32>  and
> http://www.opengis.net/sampling/2.0
> <http://www.opengis.net/sampling/2.0> ? We had the same error in an
> earlier version of GeoSciML but I can't recall how we fixed it.
Again, no errors in oXygen but I do get errors with XML Spy. As you say the exact error varies but if I try to validate http://schemas.geosciml.org/geosciml/3.0/geosciml.xsd in XML Spy I get the error:

The schema doesn't appear to be valid by itself (as a part of another schema, it might still be OK).
	File https://www.seegrid.csiro.au/subversion/GeoSciML/ISO19156_xsd/schemas/OM/om/2.0/observation.xsd is not valid.
		'result' is already declared in schema document 'http://schemas.opengis.net/om/2.0/observation.xsd'.
			Error location: schema / element
				sch-props-correct.2: 'result' is already declared in schema document 'http://schemas.opengis.net/om/2.0/observation.xsd'.

The part of the Schema spec that XML Spy is pointing to for this to be an error is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#sch-props-correct about a schema not having more than one component with the same name but this refers to the final schema that gets constructed in the usual case according to the rules in Section 4 (http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#composition) which, as far as I can make out, mean that it is OK to be importing the same definitions twice. In the above case, for example, the documents https://www.seegrid.csiro.au/subversion/GeoSciML/ISO19156_xsd/schemas/OM/om/2.0/observation.xsd and ://schemas.opengis.net/om/2.0/observation.xsd both have the same (empty) definition for the element {http://www.opengis.net/om/2.0, result}. So again I *think* that XML Spy is wrong to say this is invalid.

HOWEVER, it is confusing at best to have definitions for the same components coming from different documents so I suggest we try to get rid of these cases anyway. (I guess the 

I haven't yet double checked that the error Bruce S reported is of exactly the same nature as the one I describe above but they look similar. The case above has a seegrid copy of OM schemas which we should easily be able to replace by the one on schemas.opengis.net but it might not be quite the same with Bruce's example.


This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.

More information about the GeoSciML mailing list