[GeoSciML] GeoSciML schematron quirks [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Mon Oct 22 19:50:28 EDT 2012

Hi Marcus,

I agree that the Schematron full.referential.integrity tests have limited value, given the false errors they flag and the inability to test for sensible content of a resolvable http link.  If we need to test for resolvability of URI links, I think we should find another way.


-----Original Message-----
From: geosciml-bounces+oliver.raymond=ga.gov.au at lists.opengeospatial.org [mailto:geosciml-bounces+oliver.raymond=ga.gov.au at lists.opengeospatial.org] On Behalf Of Sen, Marcus A.
Sent: Monday, 22 October 2012 20:03
To: geosciml at lists.opengeospatial.org
Subject: Re: [GeoSciML] GeoSciML schematron quirks [SEC=UNCLASSIFIED]

> -----Original Message-----
> From: Oliver.Raymond at ga.gov.au [mailto:Oliver.Raymond at ga.gov.au]
> Sent: 22 October 2012 04:07
> To: Sen, Marcus A.
> Cc: geosciml at lists.opengeospatial.org
> Subject: GeoSciML schematron quirks [SEC=UNCLASSIFIED]
> Hi Marcus et al,
> I have been running instance docs through the Schematron validation,
> using both the CSIRO schematron tool
> (http://xmldev.arrc.csiro.au/Schematron/) and my local Oxygen
> application, and I'm getting odd errors:
It looks like you've had several replies before I got into work this morning :-)

The external.referential.integrity tests are pretty simplistic in that they just use the document() function and pass if something comes back and don't if it yields nothing. As far as I'm aware there is no way to configure in Schematron (i.e. in XSLT/XPath) control over how redirects etc. are handled, and there is no way to configure timeouts. These tests can also give slightly variable results depending on network responsiveness. These tests have existed since Bruce and Pavel's original versions and it seems a reasonable thing to check but I'm not sure whether Schematron is actually up to the job of doing this reliably. I don't know whether the Teamengine framework might be able to handle this kind of test better. So these tests can probably only be regarded as a possibly helpful warning of something you should check manually. In fact, even if the tests pass, it just means something was retrieved by resolving the URI, not that something relevant or useful was there so maybe their value is moot?

I'm open to (i) any technical suggestions about how these tests could be implemented more reliably and (ii) opinions on whether these tests are worth retaining in their present form.

The cgi.profile tests against CGI vocabularies are done against local files with the CGI URIs in to avoid this issue (and also the fact that the structure of the vocabulary documents is not easy to process consistently with XPath expressions.)


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.

Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks.

More information about the GeoSciML mailing list