[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?
Cheers
----------------------------------------------------
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
Australia
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 (
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
Details
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.
Marcus
--
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
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
Notice:
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