metadata updates

- GISC Tokyo has loaded GTS baseline metadata for VBRR, VNNN, VTBB, VLIV,
VMMC, RPMM, VHHH.
- Set WIS-WIMMS created.
- most of WISTEST-JMA set has been deleted; right now deletion in terms of
OAI so other synching centres may harvest that del-notification to react.
Four records are kept just for testing.

WIS Sync Monitor revived

My monitor has been refreshed. It has now updated list of servers and sets,
and there is a bit nicer top page with minimal description.

http://toyoda-eizi.net/2011/syncmon/mon.html

all records in WIS-GISC-TOKYO confirmed to have non-empty dateStamp

Hi,

I've run a test program to check all records in WIS-GISC-TOKYO set. This
time no record has gco:nilReason="missing".

Best,
Eizi

WDCGG metadata updated tentatively

Hi,

I've uploaded 1653 records of DAR metadata for WDCGG. There was problem in
converter from GAWSIS format to ISO 19139, which generated <gmd:dateStamp
gco:nilReason="missing"/> for most of records. Now that should be fixed.

This is only a quick fix: the metadata is all tested to be compliant to ISO
19139 schema, but there should be considerable difference of "style" from
recent agreements in IPET-MDI (and hence the latest version of MF baseline
metadata).

--
Best,
Eizi

resourceFormat and distributionFormat

Now I'm writing schematron to examine how elements of ISO 19115 is used in
actual WIS Initial MD Set.

Today I had to write following schematron.

<pattern name="fmts-eqv">
<!-- activates only if there is resourceFormat -->
<rule context="gmd:resourceFormat">
<assert test="(*/gmd:name/*/text()
=
/*/gmd:distributionInfo/*/gmd:distributionFormat/*/gmd:name/*/text())
or ('BUFR'
=
/*/gmd:distributionInfo/*/gmd:distributionFormat/*/gmd:name/*/text())
or ('CREX'
=
/*/gmd:distributionInfo/*/gmd:distributionFormat/*/gmd:name/*/text())
">resourceFormat/name and distributionFormat/name <!--
-->must be equal, or the latter be BUFR/CREX</assert>
</rule>
</pattern>

Please tolerate I had to write three similar comparisons since libxml2
doesn't support match() function.

The point is resourceFormat/*/name does not necessarily equal to
distributionFormat/*/name. Surprising, isn't it?

That takes place for TDCF (i.e. BUFR and CREX) messages converted from
alphanumeric data. This is very interesting and (so far) practical
approach. But there's also limitation. I'm curious what to do if TDCF is
directly created at the data source.

GISC Tokyo website now operational

a patch for GNOME libxml2 to work with GML XML Schema

Caution: this only suppresses error abortion. I didn't read in depth
and can't guarantee the consequences.

--- xmlschemas.c.orig 2011-04-24 14:58:16.000000000 +0000
+++ xmlschemas.c 2011-04-24 15:47:50.000000000 +0000
@@ -15158,7 +15158,11 @@
}
if ( (WXS_IS_LIST(type) || WXS_IS_UNION(type)) &&
(WXS_IS_RESTRICTION(type) == 0) &&
- (! WXS_IS_ANY_SIMPLE_TYPE(baseType))) {
+ (
+ (! WXS_IS_ANY_SIMPLE_TYPE(baseType))
+ && (baseType->type != XML_SCHEMA_TYPE_SIMPLE)
+ )
+ ) {
xmlSchemaPCustomErr(ctxt,
XML_SCHEMAP_ST_PROPS_CORRECT_1,
WXS_BASIC_CAST type, NULL,