Hi list,
I have encountered a couple of ISO19139 profiles which require the metadata id
to be in a specific format, not the classic UUID.
For instance, one of them requires a classic UUID string to be enclosed in
braces (e.g {7dd0b446-81b1-4036-8f08-2a9496a67017}), while another one
requires a locally defined fixed string appended to a custom format timestamp.
Now, when GeoNetwork needs to set an UUID to a metadata (or wherever a new id
is needed) it calls
UUID.randomUUID().toString();
and it seems there's no way to redefine it.
Should this behavior be changed, we need it to be generic enough to allow for
schemas to generate ids as custom strings using XSL, but feeding some values
as a starting point.
This means that, as a first step, it could be implemented by defining for each
schema an xsl file called something like
"build-metadata-id.xsl" which could take as input some values, let's say in
xml format, like:
<idseeds>
<uuid>_random_generated_id</uuid>
<timestamp>quite_precise_timestamp_</timestamp>
</idseeds>
Here the uuid value would be generated using the UUID.randomUUID() call.
The timestamp would be in a fixed format, offering as many fields as possible;
the xsl, using standard string manipulation functions could extract the
substring it needs; optionally the timestamp could expose the various fields as
normalized values (year, month, dayofweek, dayof year, millisc, etc)
Before writing a "formal" proposal I'd like to know if any of you already
found any similar requirements, and if this solution make any sense to you or
I may have overlooked simpler/existing ways to solve this issue.
Ciao,
Emanuele
--
Ing. Emanuele Tajariol
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
Ciao Francois,
thanks, I'll try this way.
And XSLT functions should be enough for creating timestamps.
Ciao,
Emanuele
Alle 16:38:38 di Monday 11 November 2013, Francois Prunayre ha scritto:
Hi Emanuele,
2013/11/11 Emanuele Tajariol <etj@anonymised.com>
> Hi list,
>
> I have encountered a couple of ISO19139 profiles which require the
> metadata id
> to be in a specific format, not the classic UUID.
> For instance, one of them requires a classic UUID string to be enclosed
> in braces (e.g {7dd0b446-81b1-4036-8f08-2a9496a67017}), while another
> one requires a locally defined fixed string appended to a custom format
> timestamp.
>
> Now, when GeoNetwork needs to set an UUID to a metadata (or wherever a
> new id
> is needed) it calls
>
> UUID.randomUUID().toString();
>
> and it seems there's no way to redefine it.
>
> Should this behavior be changed, we need it to be generic enough to allow
> for
> schemas to generate ids as custom strings using XSL, but feeding some
> values
> as a starting point.
> This means that, as a first step, it could be implemented by defining for
> each
> schema an xsl file called something like
> "build-metadata-id.xsl" which could take as input some values, let's say
> in xml format, like:
> <idseeds>
>
> <uuid>_random_generated_id</uuid>
> <timestamp>quite_precise_timestamp_</timestamp>
>
> </idseeds>
For some ISO profile, I've been using the readwriteuuid in schema-ident.xml
[1][2] and then customize the UUID in update-fixed-info.
In my use case, the UUID was based on the resource identifier and the
catalog URL.
That should work for you.
Ciao.
Francois
[1]
https://github.com/geonetwork/core-geonetwork/blob/develop/web/src/main/web
app/xml/validation/schemaPlugins/schema-ident.xsd#L57 [2]
http://trac.osgeo.org/geonetwork/ticket/1205
> Here the uuid value would be generated using the UUID.randomUUID() call.
> The timestamp would be in a fixed format, offering as many fields as
> possible;
> the xsl, using standard string manipulation functions could extract the
> substring it needs; optionally the timestamp could expose the various
> fields as
> normalized values (year, month, dayofweek, dayof year, millisc, etc)
>
>
> Before writing a "formal" proposal I'd like to know if any of you already
> found any similar requirements, and if this solution make any sense to
> you or
> I may have overlooked simpler/existing ways to solve this issue.
>
> Ciao,
> Emanuele
>
--
Ing. Emanuele Tajariol
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------