[Geonetwork-devel] Validation of XML against ISO 19139 XSDs and other ISO 19115 rules

Hockaday_John · May 18, 2006, 1:50am

Hi all,

I am new to GeoNetwork. I sent this email to the GeoNetwork users list but
received no replies so I am sending it to the developers list. This email
describes essential user requirements that need to be part of the development
for GeoNetwork to correctly implement ISO 19115 and relevant profiles.

I have been following the development of the ISO 19139 XSDs and noticed that
the "final" XSDs are available from
http://eden.ign.fr/xsd/isotc211/index_html?set_language=en&cl=en I have
downloaded these XSDs and validated them using Xerces-J and full-schema
checking. I have also noticed that GeoNetwork is using a very old format for
the XML that it generates for the ISO 19115 metadata.

In 2006-05-02 Jeroen Ticheler mentions:

"With the ISO19139 now almost ready, we are working on a migration to
ISO19115:2003 validated using the 19139 schemas, but as said, this is not
[expected to be] ready within the coming 6 months except for some beta
versions".

This places the ISO 19139 work to be released in 2006-11.

There are three issues that seem to be not covered by the above mentioned
proposed release:

1. GeoNetwork needs to allow the user to identify all the validation rules
necessary for proof of compliance to ISO 19115 that are not provided by the
ISO 19139 XSDs; and

2. GeoNetwork needs to somehow allow all ISO 19115 profiles that are expected
to be created for different countries and communities of practices to
implement ISO 19115 and ISO 19139.

3. GeoNetwork needs to allow inheritance between metadata records.

Discussion item 1:

To allow flexibility the ISO 19139 XSDs do not provide code lists. For
example, each of the 24 Code lists in section B.5 of ISO 19115 can be
extended and supplied in different languages. Therefore, it is expected that
these appropriate code lists will be defined in the profiles that implement
ISO 19139.

Many of the conditional statements in ISO 19115 (shown in comment boxes in
the UML diagrams) are not validated by the ISO 19139 XSDs. Conditions such
as, "hierarchyLevel" and "hierarchyLevelName" are mandatory if not equal to
"dataset"; "topicCategory" is only mandatory if hierarchyLevel equals
"dataset" or "series"; "GeographicBoundingBox" and/or "GeographicDescription"
are mandatory if hierarchyLevel equals "dataset". These conditions will need
to be validated using Schematron or XSL. This does not appear to be
available in GeoNetwork.

GeoNetwork will need to provide a two parse process to apply these rules.
The first validation is against the ISO 19139 XSDs to prove compliance to
this specification and the second validation using Schematron or XSLs to
prove compliance of the conditional statements, code lists and profile
extensions for ISO 19115. There will also be the need to convert from one
profile to ISO 19139 format using some form of XSL.

Discussion item 2:

GeoNetwork will need to be configurable to allow the profiles that meet
different countries', organisations' or communities of practices' needs. ISO
19115 profiles should consist of: XSDs that are clones or import and extend
the ISO 19139 XSDs, code lists that implement those in ISO 19115, XSLs that
translate the profile's XML format into the ISO 19139 XML format for
validation to prove compliance to ISO 19139, namespaces to allow others to
access the profile's XSDs and validate the XML document instances against
these XSDs, registration with an ISO approved registrar to prove acceptance
of the profile by ISO.

Can GeoNetwork provide this flexibility to implement profiles using Jeeves or
is there a need to use some other technology like Xforms to provide these
user requirements?

Discussion item 3:

One of the most powerful features of XML is the ability to inherit
information from other XML records. ISO 19115 also identifies the need to
allow inheritance. Annexes "G" and "H" explain how this is expected to be
made available. GeoNetwork does not appear to make this option available.
The is no option to "inherit" information from another metadata record. This
is essential for the implementation of child hierarchLevels such as;
"featureType", "feature", "attributeType", "attribute", "tile",
"collectionSession", "fieldSession" etc. It is also useful for the
maintenance of often used content such as "organisationName" and its relevant
child elements similar to the normalisation capabilities of RDBMS. For
example, a metadata record could contain the contact details of an
organisation. This information can be obtained by other metadata records
using inheritance. If that organisation changes its name, address, phone
numbers, email address or any other contact details then these changes only
need to be made in the parent metadata record rather than every single
metadata record. The children metadata records would inherit these changes
without direct editing the child's content.

Will the next release of GeoNetwork provide inheritance?

I have also found some other smaller issues with GeoNetwork that do not
comply with ISO 19115. Here is a small but not comprehensive list:

1. The domain of the content of the "language" element is ISO 639-2. "-2"
specifies the three letter abbreviation used for different countries. "-1"
specifies the two letter abbreviation. Therefore, the pick list for the
"language" element should contain three letter values like "eng" for
"English" not two letter values like "en".

2. The domain for the "dateStamp" element is "Date". "Date" is an ISO 8601
date format not an ISO 8601 DateTime format. GeoNetwork prompts a dateTime
format in the content of the "dateStamp" element. It should be a "Date"
format. For example, yyyy-mm-dd, yyyymmdd, yyyy-mm, yyyy or yy (for the
century although this is not available in the W3C XML Schema implementation)
not yyyy-mm-ddThh:mm:ss. DateTime formats should also include the time zone
eg. yyyy-mm-ddThh:MM:ss+Z so that local times can be used rather than GMT.

3. The "Default view" for creating metadata shows the "identificationInfo" as
the first list of items to be filled out. The condition of many other
elements depends on the type of metadata being filled out. That is,
"hierarchyLevel". It is important to identify other metadata elements early
in the creation of metadata such as, "language" (What language to use for the
metadata), "parentIdentifier" (From what metadata records should content be
inherited), "characterSet" (What characters do you need to enter your
metadata). I would expect that the very first options that a user should
select are these elements. Of course default values should be prompted for
these elements but the user should be able to change them so that the content
of other metadata elements can be determined.

4. GeoNetwork doesn't seem to contain some of the corrections made in the ISO
19115 Corrigendum. The Corrigendum has been approved for publishing by ISO.
When will GeoNetwork reflect these corrections?

I hope that this information helps and thank you to anyone who replies to
this email.

John Hockaday
Geoscience Australia
GPO Box 378
Canberra ACT 2601
(02) 6249 9735
http://www.ga.gov.au/
john.hockaday\@ga.gov.au

ticheler · May 18, 2006, 3:04pm

Hi John,
Sorry for the late response. You email is very to the point and much appreciated! We need some time to study parts of it. I add a reply to the first trivial question Andrea is answering the discussion items now too.
Thanks again!
Jeroen

On May 18, 2006, at 3:50 AM, John.Hockaday@anonymised.com wrote:

Hi all,

I am new to GeoNetwork. I sent this email to the GeoNetwork users list but
received no replies so I am sending it to the developers list. This email
describes essential user requirements that need to be part of the development
for GeoNetwork to correctly implement ISO 19115 and relevant profiles.

I have been following the development of the ISO 19139 XSDs and noticed that
the "final" XSDs are available from
eden | Équipe D'Experts en Normalisation I have
downloaded these XSDs and validated them using Xerces-J and full-schema
checking. I have also noticed that GeoNetwork is using a very old format for
the XML that it generates for the ISO 19115 metadata.

Yes, we use the DTD that was available for the final draft. Now Andrea has finished implementing an XSLT to transform that into an ISO19139 compliant metadata correcting the errors from the original structure. GeoNetwork will have that conversion as part of its migration path when upgrading from one to a next version. So version GN 2.0 will be converted into 19139 structure when migrating to GeoNetwork 2.1 that is scheduled for release in September. First alpha releases will come out within 2 or 3 weeks. We use the latest schemas you refer to above.

In 2006-05-02 Jeroen Ticheler mentions:

"With the ISO19139 now almost ready, we are working on a migration to
ISO19115:2003 validated using the 19139 schemas, but as said, this is not
[expected to be] ready within the coming 6 months except for some beta
versions".

This places the ISO 19139 work to be released in 2006-11.

There are three issues that seem to be not covered by the above mentioned
proposed release:

1. GeoNetwork needs to allow the user to identify all the validation rules
necessary for proof of compliance to ISO 19115 that are not provided by the
ISO 19139 XSDs; and

2. GeoNetwork needs to somehow allow all ISO 19115 profiles that are expected
to be created for different countries and communities of practices to
implement ISO 19115 and ISO 19139.

3. GeoNetwork needs to allow inheritance between metadata records.

Discussion item 1:

To allow flexibility the ISO 19139 XSDs do not provide code lists. For
example, each of the 24 Code lists in section B.5 of ISO 19115 can be
extended and supplied in different languages. Therefore, it is expected that
these appropriate code lists will be defined in the profiles that implement
ISO 19139.

Many of the conditional statements in ISO 19115 (shown in comment boxes in
the UML diagrams) are not validated by the ISO 19139 XSDs. Conditions such
as, "hierarchyLevel" and "hierarchyLevelName" are mandatory if not equal to
"dataset"; "topicCategory" is only mandatory if hierarchyLevel equals
"dataset" or "series"; "GeographicBoundingBox" and/or "GeographicDescription"
are mandatory if hierarchyLevel equals "dataset". These conditions will need
to be validated using Schematron or XSL. This does not appear to be
available in GeoNetwork.

GeoNetwork will need to provide a two parse process to apply these rules.
The first validation is against the ISO 19139 XSDs to prove compliance to
this specification and the second validation using Schematron or XSLs to
prove compliance of the conditional statements, code lists and profile
extensions for ISO 19115. There will also be the need to convert from one
profile to ISO 19139 format using some form of XSL.

Discussion item 2:

GeoNetwork will need to be configurable to allow the profiles that meet
different countries', organisations' or communities of practices' needs. ISO
19115 profiles should consist of: XSDs that are clones or import and extend
the ISO 19139 XSDs, code lists that implement those in ISO 19115, XSLs that
translate the profile's XML format into the ISO 19139 XML format for
validation to prove compliance to ISO 19139, namespaces to allow others to
access the profile's XSDs and validate the XML document instances against
these XSDs, registration with an ISO approved registrar to prove acceptance
of the profile by ISO.

Can GeoNetwork provide this flexibility to implement profiles using Jeeves or
is there a need to use some other technology like Xforms to provide these
user requirements?

Discussion item 3:

One of the most powerful features of XML is the ability to inherit
information from other XML records. ISO 19115 also identifies the need to
allow inheritance. Annexes "G" and "H" explain how this is expected to be
made available. GeoNetwork does not appear to make this option available.
The is no option to "inherit" information from another metadata record. This
is essential for the implementation of child hierarchLevels such as;
"featureType", "feature", "attributeType", "attribute", "tile",
"collectionSession", "fieldSession" etc. It is also useful for the
maintenance of often used content such as "organisationName" and its relevant
child elements similar to the normalisation capabilities of RDBMS. For
example, a metadata record could contain the contact details of an
organisation. This information can be obtained by other metadata records
using inheritance. If that organisation changes its name, address, phone
numbers, email address or any other contact details then these changes only
need to be made in the parent metadata record rather than every single
metadata record. The children metadata records would inherit these changes
without direct editing the child's content.

Will the next release of GeoNetwork provide inheritance?

I have also found some other smaller issues with GeoNetwork that do not
comply with ISO 19115. Here is a small but not comprehensive list:

1. The domain of the content of the "language" element is ISO 639-2. "-2"
specifies the three letter abbreviation used for different countries. "-1"
specifies the two letter abbreviation. Therefore, the pick list for the
"language" element should contain three letter values like "eng" for
"English" not two letter values like "en".

2. The domain for the "dateStamp" element is "Date". "Date" is an ISO 8601
date format not an ISO 8601 DateTime format. GeoNetwork prompts a dateTime
format in the content of the "dateStamp" element. It should be a "Date"
format. For example, yyyy-mm-dd, yyyymmdd, yyyy-mm, yyyy or yy (for the
century although this is not available in the W3C XML Schema implementation)
not yyyy-mm-ddThh:mm:ss. DateTime formats should also include the time zone
eg. yyyy-mm-ddThh:MM:ss+Z so that local times can be used rather than GMT.

3. The "Default view" for creating metadata shows the "identificationInfo" as
the first list of items to be filled out. The condition of many other
elements depends on the type of metadata being filled out. That is,
"hierarchyLevel". It is important to identify other metadata elements early
in the creation of metadata such as, "language" (What language to use for the
metadata), "parentIdentifier" (From what metadata records should content be
inherited), "characterSet" (What characters do you need to enter your
metadata). I would expect that the very first options that a user should
select are these elements. Of course default values should be prompted for
these elements but the user should be able to change them so that the content
of other metadata elements can be determined.

4. GeoNetwork doesn't seem to contain some of the corrections made in the ISO
19115 Corrigendum. The Corrigendum has been approved for publishing by ISO.
When will GeoNetwork reflect these corrections?

I hope that this information helps and thank you to anyone who replies to
this email.

John Hockaday
Geoscience Australia
GPO Box 378
Canberra ACT 2601
(02) 6249 9735
http://www.ga.gov.au/
john.hockaday\@ga.gov.au

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmdlnk&kid0709&bid&3057&dat1642
_______________________________________________
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

Andrea_Carboni1 · May 19, 2006, 2:31pm

Hi John,

here are my answers and comments.

I have been following the development of the ISO 19139 XSDs and noticed that
the "final" XSDs are available from
http://eden.ign.fr/xsd/isotc211/index_html?set_language=en&cl=en I have
downloaded these XSDs and validated them using Xerces-J and full-schema
checking. I have also noticed that GeoNetwork is using a very old format for
the XML that it generates for the ISO 19115 metadata.

In 2006-05-02 Jeroen Ticheler mentions:

"With the ISO19139 now almost ready, we are working on a migration to
ISO19115:2003 validated using the 19139 schemas, but as said, this is not
[expected to be] ready within the coming 6 months except for some beta
versions".

This places the ISO 19139 work to be released in 2006-11.

I have finished a set of stylesheets that convert an ISO19115 metadata to
its 2003 (19139) equivalent. I will commit them within a few days so
interested users can use them to do some tests/debugging. We used them
to migrate our metadata and they seem to work.

When you will do a 'cvs up' you will get a new folder named 'migrate'.
The stylesheets are in 'migrate/xsl'. There is one more stylesheet, named
'unmapped.xsl' which takes an ISO 19115 metadata and reports the
elements that cannot be mapped (if any).

Discussion item 1:

To allow flexibility the ISO 19139 XSDs do not provide code lists. For
example, each of the 24 Code lists in section B.5 of ISO 19115 can be
extended and supplied in different languages. Therefore, it is expected that
these appropriate code lists will be defined in the profiles that implement
ISO 19139.

I don't understand this point. Actually, the 19139 defines many codelists
(I'm referring to the xml schema, I didn't read the specification).
For each codelist, the sets of allowed values is not enforced into the xml
schema but simply declared in an external xml file. These values should
obviously be localized.

Many of the conditional statements in ISO 19115 (shown in comment boxes in
the UML diagrams) are not validated by the ISO 19139 XSDs. Conditions such
as, "hierarchyLevel" and "hierarchyLevelName" are mandatory if not equal to
"dataset"; "topicCategory" is only mandatory if hierarchyLevel equals
"dataset" or "series"; "GeographicBoundingBox" and/or "GeographicDescription"
are mandatory if hierarchyLevel equals "dataset". These conditions will need
to be validated using Schematron or XSL. This does not appear to be
available in GeoNetwork.

GeoNetwork will need to provide a two parse process to apply these rules.
The first validation is against the ISO 19139 XSDs to prove compliance to
this specification and the second validation using Schematron or XSLs to
prove compliance of the conditional statements, code lists and profile
extensions for ISO 19115. There will also be the need to convert from one
profile to ISO 19139 format using some form of XSL.

I agree.

From a programming point of view a two phase validation (against the schema
and against the rules) is very easy to achieve. The problem here is the creation
of the stylesheet for the second pass.

Anyway, even a simple validation could not succed. If geonetwork starts from
a valid metadata it cannot guarantee that after an edit operation the metadata
is still valid. When you create a node into the metadata you have to create
all mandatory subnodes. Some of them are simple nodes but other are mandatory
choices between several nodes. In this case the user must supply more information
and untill that point the metadata is not invalid.

Discussion item 2:

GeoNetwork will need to be configurable to allow the profiles that meet
different countries', organisations' or communities of practices' needs. ISO
19115 profiles should consist of: XSDs that are clones or import and extend
the ISO 19139 XSDs, code lists that implement those in ISO 19115, XSLs that
translate the profile's XML format into the ISO 19139 XML format for
validation to prove compliance to ISO 19139, namespaces to allow others to
access the profile's XSDs and validate the XML document instances against
these XSDs, registration with an ISO approved registrar to prove acceptance
of the profile by ISO.

Can GeoNetwork provide this flexibility to implement profiles using Jeeves or
is there a need to use some other technology like Xforms to provide these
user requirements?

I don't have a deep knowledge on the several iso profiles. IMHO, there should
be only one standard (19139) to follow without changes/customizations to
suit a particular country. Anyway, I know that there are some countries for
which the standard is not enough and that want to change some parts (for
example France). I think this is the scenario you have in mind.

If this is the case, geonetwork can manage all iso dialects but as different
standards, the same way it handles DC and FGDC. The possibility to have
a basic 19139 schema and to allow several profiles has not be taken into
account. This flexibility is not even simple to add.

Discussion item 3:

One of the most powerful features of XML is the ability to inherit
information from other XML records. ISO 19115 also identifies the need to
allow inheritance. Annexes "G" and "H" explain how this is expected to be
made available. GeoNetwork does not appear to make this option available.
The is no option to "inherit" information from another metadata record. This
is essential for the implementation of child hierarchLevels such as;
"featureType", "feature", "attributeType", "attribute", "tile",
"collectionSession", "fieldSession" etc. It is also useful for the
maintenance of often used content such as "organisationName" and its relevant
child elements similar to the normalisation capabilities of RDBMS. For
example, a metadata record could contain the contact details of an
organisation. This information can be obtained by other metadata records
using inheritance. If that organisation changes its name, address, phone
numbers, email address or any other contact details then these changes only
need to be made in the parent metadata record rather than every single
metadata record. The children metadata records would inherit these changes
without direct editing the child's content.

Will the next release of GeoNetwork provide inheritance?

In geonetwork 1 we had a separate table to store common ResponsibleParty
elements but then we removed this option to keep things simple and to
allow the validation against our old DTD. If this possibility is provided by
the new 19139 specification then I agree with you to use it. Here issues
are only technical.

Anyway, this feature is not planned. We are still missing some important
features due to lack of money so I don't think we have the resources to do that.

I have also found some other smaller issues with GeoNetwork that do not
comply with ISO 19115. Here is a small but not comprehensive list:

1. The domain of the content of the "language" element is ISO 639-2. "-2"
specifies the three letter abbreviation used for different countries. "-1"
specifies the two letter abbreviation. Therefore, the pick list for the
"language" element should contain three letter values like "eng" for
"English" not two letter values like "en".

The list is filled with elements taken from the DTD. The set of elements
specified into the 19139 schema seem to be the same (2 letters).
Maybe this point requires more investigation.

2. The domain for the "dateStamp" element is "Date". "Date" is an ISO 8601
date format not an ISO 8601 DateTime format. GeoNetwork prompts a dateTime
format in the content of the "dateStamp" element. It should be a "Date"
format. For example, yyyy-mm-dd, yyyymmdd, yyyy-mm, yyyy or yy (for the
century although this is not available in the W3C XML Schema implementation)
not yyyy-mm-ddThh:mm:ss. DateTime formats should also include the time zone
eg. yyyy-mm-ddThh:MM:ss+Z so that local times can be used rather than GMT.

Ok, we can fix it.

3. The "Default view" for creating metadata shows the "identificationInfo" as
the first list of items to be filled out. The condition of many other
elements depends on the type of metadata being filled out. That is,
"hierarchyLevel". It is important to identify other metadata elements early
in the creation of metadata such as, "language" (What language to use for the
metadata), "parentIdentifier" (From what metadata records should content be
inherited), "characterSet" (What characters do you need to enter your
metadata). I would expect that the very first options that a user should
select are these elements. Of course default values should be prompted for
these elements but the user should be able to change them so that the content
of other metadata elements can be determined.

We can try to rearrange the panels.

4. GeoNetwork doesn't seem to contain some of the corrections made in the ISO
19115 Corrigendum. The Corrigendum has been approved for publishing by ISO.
When will GeoNetwork reflect these corrections?

I'm not aware of this. We have to see if the migration to the 19139 fixes the problem.

I hope that this information helps and thank you to anyone who replies to
this email.

It will help for sure.

Cheers,
Andrea

ticheler · May 19, 2006, 2:46pm

John and Andrea,
Just one more comment on the point below. I have been looking into this not so long ago when we were adding convenience calendars to the editor. John, you are right about the format of that field. However, there is a problematic issue for which we do not have an answer here and that causes us to actually fill out the field as if it were a DateTime:To know when a metadata has been updated, it is not enough to know the day. For many cases you really need to know exactly when the update occurred. For instance, when we compare two metadata while harvesting from a system, we have to know exactly when that metadata was updated last. The same is true for trivial functions like: what metadata records have a creation date and dateStamp that only differ by e.g. 1 minute? We can use this to retrieve metadata records that were added, but than not updated/ edited online by a user and that may therefor be empty left over records that an admin can clean up.
Any suggestions on this are very welcome!
Ciao,
Jeroen

On May 19, 2006, at 4:31 PM, Andrea Carboni wrote:

The domain for the “dateStamp” element is “Date”. “Date” is an ISO 8601

date format not an ISO 8601 DateTime format. GeoNetwork prompts a dateTime

format in the content of the “dateStamp” element. It should be a “Date”

format. For example, yyyy-mm-dd, yyyymmdd, yyyy-mm, yyyy or yy (for the

century although this is not available in the W3C XML Schema implementation)

not yyyy-mm-ddThh:mm:ss. DateTime formats should also include the time zone

eg. yyyy-mm-ddThh:MM:ss+Z so that local times can be used rather than GMT.

Ok, we can fix it.

Andrea_Carboni1 · May 19, 2006, 2:53pm

Jeroen,

this is not a problem. We have 2 fields into the Metadata table (createDate
and lastChangeDate) that were added to fill this need.

The only concern here is if the date format yyyy-mm-dd is enough for the
metadata itself.

Cheers,
Andrea

John and Andrea,
Just one more comment on the point below. I have been looking into
this not so long ago when we were adding convenience calendars to the
editor. John, you are right about the format of that field. However,
there is a problematic issue for which we do not have an answer here
and that causes us to actually fill out the field as if it were a
DateTime:
To know when a metadata has been updated, it is not enough to know
the day. For many cases you really need to know exactly when the
update occurred. For instance, when we compare two metadata while
harvesting from a system, we have to know exactly when that metadata
was updated last. The same is true for trivial functions like: what
metadata records have a creation date and dateStamp that only differ
by e.g. 1 minute? We can use this to retrieve metadata records that
were added, but than not updated/ edited online by a user and that
may therefor be empty left over records that an admin can clean up.
Any suggestions on this are very welcome!
Ciao,
Jeroen

On May 19, 2006, at 4:31 PM, Andrea Carboni wrote:

>> 2. The domain for the "dateStamp" element is "Date". "Date" is an
>> ISO 8601
>> date format not an ISO 8601 DateTime format. GeoNetwork prompts a
>> dateTime
>> format in the content of the "dateStamp" element. It should be a
>> "Date"
>> format. For example, yyyy-mm-dd, yyyymmdd, yyyy-mm, yyyy or yy
>> (for the
>> century although this is not available in the W3C XML Schema
>> implementation)
>> not yyyy-mm-ddThh:mm:ss. DateTime formats should also include the
>> time zone
>> eg. yyyy-mm-ddThh:MM:ss+Z so that local times can be used rather
>> than GMT.
>
> Ok, we can fix it.

ticheler · May 19, 2006, 3:41pm

Right, so that’s partly good news
John, others, any ideas on if yyyy-mm-dd is enough for metadata?
Jeroen

On May 19, 2006, at 4:53 PM, Andrea Carboni wrote:

Jeroen,

this is not a problem. We have 2 fields into the Metadata table (createDate

and lastChangeDate) that were added to fill this need.

The only concern here is if the date format yyyy-mm-dd is enough for the

metadata itself.

Cheers,

Andrea

John and Andrea,

Just one more comment on the point below. I have been looking into

this not so long ago when we were adding convenience calendars to the

editor. John, you are right about the format of that field. However,

there is a problematic issue for which we do not have an answer here

and that causes us to actually fill out the field as if it were a

DateTime:

To know when a metadata has been updated, it is not enough to know

the day. For many cases you really need to know exactly when the

update occurred. For instance, when we compare two metadata while

harvesting from a system, we have to know exactly when that metadata

was updated last. The same is true for trivial functions like: what

metadata records have a creation date and dateStamp that only differ

by e.g. 1 minute? We can use this to retrieve metadata records that

were added, but than not updated/ edited online by a user and that

may therefor be empty left over records that an admin can clean up.

Any suggestions on this are very welcome!

Ciao,

Jeroen

Andrea_Carboni1 · February 6, 2007, 11:18am

Hi John,

I have just finished to read both the ISO19115 and ISO19139 specs. I have
found this on page 60 of the ISO19139 spec:

---------------------
ISO 19118 directs XML encodings to use the XML Schema types for Date and
DateTime as defined in ISO/TS 19103, stating that both types have a canonical
encoding according to ISO 8601. However, there is a fundamental difference
between the Date and DateTime described in ISO/TS 19103 and the xs:date and
xs:dateTime of XML Schema. In ISO/TS 19103 DateTime is a subtype of Date,
which means that it inherits all the attributes of Date and can be used as an
alternative datatype wherever Date is the specified datatype for an attribute.
The XML Schema implementation of xs:date and xs:dateTime does not have an
equivalent model and as such xs:dateTime can NOT be used as the datatype of
attributes (or XML elements) defined with the datatype of date.
---------------------

It seems that we can use a DateTime wherever we have a Date so we don't
need to change the dateStamp element.

What do you think?

Cheers,
Andrea

2. The domain for the "dateStamp" element is "Date". "Date" is an ISO 8601
date format not an ISO 8601 DateTime format. GeoNetwork prompts a dateTime
format in the content of the "dateStamp" element. It should be a "Date"
format. For example, yyyy-mm-dd, yyyymmdd, yyyy-mm, yyyy or yy (for the
century although this is not available in the W3C XML Schema implementation)
not yyyy-mm-ddThh:mm:ss. DateTime formats should also include the time zone
eg. yyyy-mm-ddThh:MM:ss+Z so that local times can be used rather than GMT.

Tim_Jacobs · February 6, 2007, 1:50pm

Hi Andrea,

Can you please tell me where I can find those specs? I'd like to read them too.

Thanks in advance,

Tim

From: Andrea Carboni <acarboni@anonymised.com>
Reply-To: acarboni@anonymised.com
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] [Geonetwork-devel] Validation of XML againstISO 19139 XSDs and other ISO 19115 rules
Date: Tue, 6 Feb 2007 12:18:59 +0100

Hi John,

I have just finished to read both the ISO19115 and ISO19139 specs. I have
found this on page 60 of the ISO19139 spec:

---------------------
ISO 19118 directs XML encodings to use the XML Schema types for Date and
DateTime as defined in ISO/TS 19103, stating that both types have a canonical
encoding according to ISO 8601. However, there is a fundamental difference
between the Date and DateTime described in ISO/TS 19103 and the xs:date and
xs:dateTime of XML Schema. In ISO/TS 19103 DateTime is a subtype of Date,
which means that it inherits all the attributes of Date and can be used as an
alternative datatype wherever Date is the specified datatype for an attribute.
The XML Schema implementation of xs:date and xs:dateTime does not have an
equivalent model and as such xs:dateTime can NOT be used as the datatype of
attributes (or XML elements) defined with the datatype of date.
---------------------

It seems that we can use a DateTime wherever we have a Date so we don't
need to change the dateStamp element.

What do you think?

Cheers,
Andrea

> 2. The domain for the "dateStamp" element is "Date". "Date" is an ISO 8601
> date format not an ISO 8601 DateTime format. GeoNetwork prompts a dateTime
> format in the content of the "dateStamp" element. It should be a "Date"
> format. For example, yyyy-mm-dd, yyyymmdd, yyyy-mm, yyyy or yy (for the
> century although this is not available in the W3C XML Schema implementation)
> not yyyy-mm-ddThh:mm:ss. DateTime formats should also include the time zone
> eg. yyyy-mm-ddThh:MM:ss+Z so that local times can be used rather than GMT.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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

_________________________________________________________________
A lot of passions? Collect all your personal info on one central location , for free! http://get.live.com/live/features