+1
I'm keen to explore parallels like plugin profiles and use of geonetwork in the national (geo)portal role
Cheers,
Simon
Is there anyone looking at upgrading the validation of records? Particularly
the reporting of errors from failed validation? This affects many areas,
manual entry, workflow, harvesting, importing etc.
-----Original Message-----
From: geonetwork-devel-bounces@lists.sourceforge.net
[mailto:geonetwork-devel-bounces@lists.sourceforge.net] On Behalf Of Simon
Pigot
Sent: Wednesday, November 21, 2007 3:42 PM
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Motion: New committer on SVN
+1
I'm keen to explore parallels like plugin profiles and use of geonetwork
in the national (geo)portal role
Cheers,
Simon
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
Hi Mike,
I think I've taken on responsibility for this as a result of the schematron additions (as originally proposed by John Hockaday) that I spoke about at the Geonetwork technical workshop. I think improvements to validation (against the XSDs) reporting should be rolled into a proposal that also includes the schematron processing.
Currently I'm building a test of the schematron processing (from the ANZLIC MET version of GN 2.0.3) into 2.1 to provide some proof of concept for the proposal.
For manual entry, validation is dependent on improvements to schema parsing and the editor that I'm also doing the proposal for, namely:
- full and correct parsing of the 19139/19119 schemas (currently being tested by Bluenet staff)
- Ajax techniques for the editor
The importance of the first dot point is obvious but the second is also important as the schematron validation occurs during editing and the user needs to have a clear idea of which schematron rules/assertions are firing and why and which element they fired against - Ajax techniques for showing this (and the rest of the editor interface) would be a lot nicer than the current alert button in the ANZLIC MET version of GN 2.0.3 (I think Ajax interfaces are kind of gimmicky but the editor is looking dated now when compared with the rest of the "Ajaxified" GN 2.1).
As the editor also includes a "validate" button, the current idea in the ANZLIC MET that is being worked into the 2.1 testbed is to provide a two stage validation report: first against the XSD (with a more sophisticated error reporting mechanism still to be worked out) and the second with schematron validation with reporting via schematron-report.xsl or diagnostics from ISO schematron.
For harvesting, importing etc - ie. validation of more than one record in the catalogue - then perhaps reports from the two stage validation process can be produced for each record - its not a big step from the 2.1 test implementation of the "validate" button that I have already in the ANZLIC MET - the reports that would be produced by the "validate" button are simply generated for a set of records and stored (by UUID?) for retrieval by the user.
More discussion required I suspect!
Cheers,
Simon
Michael Gannon wrote:
Is there anyone looking at upgrading the validation of records? Particularly
the reporting of errors from failed validation? This affects many areas,
manual entry, workflow, harvesting, importing etc.-----Original Message-----
From: geonetwork-devel-bounces@lists.sourceforge.net
[mailto:geonetwork-devel-bounces@lists.sourceforge.net] On Behalf Of Simon
Pigot
Sent: Wednesday, November 21, 2007 3:42 PM
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Motion: New committer on SVN+1
I'm keen to explore parallels like plugin profiles and use of geonetwork in the national (geo)portal role
Cheers,
Simon-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at
GeoNetwork - Geographic Metadata Catalog download | SourceForge.net
Hi Simon,
That all sounds great, the part that I was particularly eluding to was
addressed by you with this:
"first against the XSD (with a more sophisticated error reporting mechanism
still to be worked out)"
While I appreciate the space the Schematron works in there is likely to be
more errors, and more cryptic errors thrown from XSD's than the Schematron.
Just to throw my 2cents in I would have through fixing the reporting of XSD
errors would have come well before implementing Schematron (although I know
where you are coming form with the ANZLIC requirements) giving you a stable
place to work from in implementing further validation be it XSLT, SCH etc.
That's just my 2cents but it looks like we are getting there. If you had to
put a time on it, or perhaps a version might be more appropriate, when would
you hope to see some of this work fixing the error reporting with XSD's
getting into the stable builds?
Mik.
-----Original Message-----
From: geonetwork-devel-bounces@lists.sourceforge.net
[mailto:geonetwork-devel-bounces@lists.sourceforge.net] On Behalf Of Simon
Pigot
Sent: Thursday, November 22, 2007 12:27 AM
To: Michael Gannon
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Motion: New committer on SVN
Hi Mike,
I think I've taken on responsibility for this as a result of the
schematron additions (as originally proposed by John Hockaday) that I
spoke about at the Geonetwork technical workshop. I think improvements
to validation (against the XSDs) reporting should be rolled into a
proposal that also includes the schematron processing.
Currently I'm building a test of the schematron processing (from the
ANZLIC MET version of GN 2.0.3) into 2.1 to provide some proof of
concept for the proposal.
For manual entry, validation is dependent on improvements to schema
parsing and the editor that I'm also doing the proposal for, namely:
- full and correct parsing of the 19139/19119 schemas (currently being
tested by Bluenet staff)
- Ajax techniques for the editor
The importance of the first dot point is obvious but the second is also
important as the schematron validation occurs during editing and the
user needs to have a clear idea of which schematron rules/assertions are
firing and why and which element they fired against - Ajax techniques
for showing this (and the rest of the editor interface) would be a lot
nicer than the current alert button in the ANZLIC MET version of GN
2.0.3 (I think Ajax interfaces are kind of gimmicky but the editor is
looking dated now when compared with the rest of the "Ajaxified" GN 2.1).
As the editor also includes a "validate" button, the current idea in the
ANZLIC MET that is being worked into the 2.1 testbed is to provide a two
stage validation report: first against the XSD (with a more
sophisticated error reporting mechanism still to be worked out) and the
second with schematron validation with reporting via
schematron-report.xsl or diagnostics from ISO schematron.
For harvesting, importing etc - ie. validation of more than one record
in the catalogue - then perhaps reports from the two stage validation
process can be produced for each record - its not a big step from the
2.1 test implementation of the "validate" button that I have already in
the ANZLIC MET - the reports that would be produced by the "validate"
button are simply generated for a set of records and stored (by UUID?)
for retrieval by the user.
More discussion required I suspect!
Cheers,
Simon
Michael Gannon wrote:
Is there anyone looking at upgrading the validation of records?
Particularly
the reporting of errors from failed validation? This affects many areas,
manual entry, workflow, harvesting, importing etc.-----Original Message-----
From: geonetwork-devel-bounces@lists.sourceforge.net
[mailto:geonetwork-devel-bounces@lists.sourceforge.net] On Behalf Of Simon
Pigot
Sent: Wednesday, November 21, 2007 3:42 PM
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Motion: New committer on SVN+1
I'm keen to explore parallels like plugin profiles and use of geonetwork
in the national (geo)portal roleCheers,
Simon-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
Michael Gannon wrote:
Hi Simon,
That all sounds great, the part that I was particularly eluding to was
addressed by you with this:"first against the XSD (with a more sophisticated error reporting mechanism
still to be worked out)"
This is the part where your input is needed 
Do you want to be able to plug in your own validation tool here (eg. xmllint) which returns an html report? If no plug in is configured then the default behaviour is the current cryptic stuff produced by the GN parser?
While I appreciate the space the Schematron works in there is likely to be
more errors, and more cryptic errors thrown from XSD's than the Schematron.
I think schematron can be used for much more than just validation as XML people understand it - think of the checks on content that could be made for an organisational metadata profile using schematron rules. So whilst I agree that the cryptic ones (including the ones that are difficult to pin down usefully) are going to come from the XSD validation, it is schematron that will probably be the most prolific once it is understood how useful it is. Anyway - this is kind of a side issue - so sorry for diverting off here.
Just to throw my 2cents in I would have through fixing the reporting of XSD
errors would have come well before implementing Schematron (although I know
where you are coming form with the ANZLIC requirements) giving you a stable
place to work from in implementing further validation be it XSLT, SCH etc.
I think from our experience in the bluenet area where entry is via the geonetwork editor and controlled by templates, there aren't that many XSD errors (when the editor understand the schema correctly! :-)) and of those many could probably be caught and reported by schematron more usefully at present - so it depends on where you're coming from. This would be different for harvested records and XML imported from other places though - particularly in organisations where ISO metadata is created from a number of different internal systems and then imported into GN so I take the point - see above.
That's just my 2cents but it looks like we are getting there. If you had to
put a time on it, or perhaps a version might be more appropriate, when would
you hope to see some of this work fixing the error reporting with XSD's
getting into the stable builds?
I don't think offering a config option to run an external validator like xmllint that produced an html report would be hard (thats what schematron does now) and I think thats the option I'll put in the 2.1 test I'm building now - but there is more out there than xmllint (don't even know if xmllint is available for windoze people) so more input is required...
Cheers,
Simon