[auscope-geosciml] GA_MappedFeature_GeologicUnit_wfs2.0 instance

Bruce.Simons at dpi.vic.gov.au Bruce.Simons at dpi.vic.gov.au
Thu May 12 19:48:34 EDT 2011

Hi Marcus,
Thanks for checking my XMLSpy issues.  Your analysis looks spot on to me 
and is much appreciated.

Do you mind if I forward this email to Altova picking up on your two 
points where XMLSpy appears to be over-prescriptive?

Bruce Simons
Senior Information Geoscientist
IUGS-Commission for Geoscience Information Oceania Councillor
GeoScience Victoria/Australian Spatial Research Data Commons
Level 9, 55 Collins St
PO Box 4440
Melbourne, Victoria, 3001

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555
Mobile: +61 429 177155

From:   "Sen, Marcus A." <mase at bgs.ac.uk>
To:     "auscope-geosciml at lists.arcs.org.au" 
<auscope-geosciml at lists.arcs.org.au>
Date:   13/05/2011 02:31 AM
Subject:        Re: [auscope-geosciml] 
GA_MappedFeature_GeologicUnit_wfs2.0 instance
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au

> -----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 (
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 

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

The part of the Schema spec that XML Spy is pointing to for this to be an 
error is 
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 
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.
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au

This email and any attachments may contain information that is personal, 
confidential, legally privileged and/or copyright.No part of it should be reproduced, 
adapted or communicated without the prior written consent of the copyright owner. 

It is the responsibility of the recipient to check for and remove viruses.
If you have received this email in error, please notify the sender by return email, delete 
it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information 
contained in this email.

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110513/dc488dcf/attachment.htm>

More information about the GeoSciML mailing list