You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2013/05/03 19:03:11 UTC
AbstractMetadata.toString() representation
Hello all
This is a minor details, but all metadata should now have 'toString()'
representation. An example is like below (needs UTF-8 encoding and
monospaced font for proper output). This example does not show much
geographic stuff, but other ISO 19115 objects are more clearly geographic.
DefaultCitation
├─Title…………………………………………………………………………………… Some title
├─Alternate title (1 of 2)………………………………… First alternate title
├─Alternate title (2 of 2)………………………………… Second alternate title
├─Edition……………………………………………………………………………… Some edition
├─Cited responsible party (1 of 2)
│ ├─Organisation name………………………………………… Some organisation
│ └─Role…………………………………………………………………………… Distributor
├─Cited responsible party (2 of 2)
│ ├─Individual name……………………………………………… Some person of contact
│ ├─Contact info
│ │ └─Address
│ │ └─Electronic mail address…… Some email
│ └─Role…………………………………………………………………………… Point of contact
├─Presentation form (1 of 2)…………………………… Map digital
├─Presentation form (2 of 2)…………………………… Map hardcopy
└─Other citation details……………………………………… Some other details
Up to now all "toString()" implementations were formatting in
Locale.ROOT (kind of "unlocalized" locale, very similar to
Locale.ENGLISH except for a few things like dates). This is because
'toString()' were mostly for debugging purposes and were intended to be
parseable for example by the org.apache.sis.measure.Angle(String)
constructor. However since I don't think that anyone will try to parse
String representation of metadata (if one want to do that, he should use
XML instead), I wonder if we should use Locale.getDefault() in the
metadata case? This impact number and date formatting, and some labels
for which a translation is available.
Same question apply to timezone, currently fixed at UTC for
AbstractMetadata.toString(). I wonder if we should use the locale
timezone...
Note that this is just for developer convenience. If such output is
desired for end-user, then the steps are to get a TreeTable
representation of the metadata, configure a TreeTableFormat and use it
like below:
AbstractMetadata myMetadata = ...; // Any of the ~80 available
subclasses.
TreeTable treeTableViewOfMyMetadata = metadata.asTreeTable();
TreeTableFormat format = new TreeTableFormat(myLocale, myTimezone);
String s = format.format(treeTableViewOfMyMetadata);
Martin
Re: AbstractMetadata.toString() representation
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Super +1, good idea, Martin.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.fr>
Organization: Geomatys
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Friday, May 3, 2013 10:11 AM
To: Apache SIS <de...@sis.apache.org>
Subject: Re: AbstractMetadata.toString() representation
>Le 03/05/13 19:03, Martin Desruisseaux a écrit :
>> Note that this is just for developer convenience. If such output is
>> desired for end-user, then the steps are to get a TreeTable
>> representation of the metadata, configure a TreeTableFormat and use it
>> like below:
>>
>> AbstractMetadata myMetadata = ...; // Any of the ~80 available
>> subclasses.
>> TreeTable treeTableViewOfMyMetadata = metadata.asTreeTable();
>> TreeTableFormat format = new TreeTableFormat(myLocale, myTimezone);
>> String s = format.format(treeTableViewOfMyMetadata);
>
>Just for the record, the code behind the above "metadata.asTreeTable()"
>method call is a complete rewrite compared to what we had in Geotk,
>which is why the port of other Geotk code has been delayed. The main
>difference is that the SIS TreeTable view is read/write (i.e. invoking
>Node.setValue(...) automatically invokes the appropriate setter methods
>on the metadata object), while the Geotk one was read only. The intend
>for this development is to make metadata TreeTable usable in GUI
>metadata editors.
>
> Martin
>
Re: AbstractMetadata.toString() representation
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 03/05/13 19:03, Martin Desruisseaux a écrit :
> Note that this is just for developer convenience. If such output is
> desired for end-user, then the steps are to get a TreeTable
> representation of the metadata, configure a TreeTableFormat and use it
> like below:
>
> AbstractMetadata myMetadata = ...; // Any of the ~80 available
> subclasses.
> TreeTable treeTableViewOfMyMetadata = metadata.asTreeTable();
> TreeTableFormat format = new TreeTableFormat(myLocale, myTimezone);
> String s = format.format(treeTableViewOfMyMetadata);
Just for the record, the code behind the above "metadata.asTreeTable()"
method call is a complete rewrite compared to what we had in Geotk,
which is why the port of other Geotk code has been delayed. The main
difference is that the SIS TreeTable view is read/write (i.e. invoking
Node.setValue(...) automatically invokes the appropriate setter methods
on the metadata object), while the Geotk one was read only. The intend
for this development is to make metadata TreeTable usable in GUI
metadata editors.
Martin
Re: AbstractMetadata.toString() representation
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
+1 to Locale.getDefault() I've seen them use that practice in Lucene+Solr.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.fr>
Organization: Geomatys
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Friday, May 3, 2013 10:03 AM
To: Apache SIS <de...@sis.apache.org>
Subject: AbstractMetadata.toString() representation
>Hello all
>
>This is a minor details, but all metadata should now have 'toString()'
>representation. An example is like below (needs UTF-8 encoding and
>monospaced font for proper output). This example does not show much
>geographic stuff, but other ISO 19115 objects are more clearly geographic.
>
>DefaultCitation
> ├─Title…………………………………………………………………………………… Some title
> ├─Alternate title (1 of 2)………………………………… First alternate title
> ├─Alternate title (2 of 2)………………………………… Second alternate title
> ├─Edition……………………………………………………………………………… Some edition
> ├─Cited responsible party (1 of 2)
> │ ├─Organisation name………………………………………… Some organisation
> │ └─Role…………………………………………………………………………… Distributor
> ├─Cited responsible party (2 of 2)
> │ ├─Individual name……………………………………………… Some person of contact
> │ ├─Contact info
> │ │ └─Address
> │ │ └─Electronic mail address…… Some email
> │ └─Role…………………………………………………………………………… Point of contact
> ├─Presentation form (1 of 2)…………………………… Map digital
> ├─Presentation form (2 of 2)…………………………… Map hardcopy
> └─Other citation details……………………………………… Some other details
>
>
>Up to now all "toString()" implementations were formatting in
>Locale.ROOT (kind of "unlocalized" locale, very similar to
>Locale.ENGLISH except for a few things like dates). This is because
>'toString()' were mostly for debugging purposes and were intended to be
>parseable for example by the org.apache.sis.measure.Angle(String)
>constructor. However since I don't think that anyone will try to parse
>String representation of metadata (if one want to do that, he should use
>XML instead), I wonder if we should use Locale.getDefault() in the
>metadata case? This impact number and date formatting, and some labels
>for which a translation is available.
>
>Same question apply to timezone, currently fixed at UTC for
>AbstractMetadata.toString(). I wonder if we should use the locale
>timezone...
>
>Note that this is just for developer convenience. If such output is
>desired for end-user, then the steps are to get a TreeTable
>representation of the metadata, configure a TreeTableFormat and use it
>like below:
>
> AbstractMetadata myMetadata = ...; // Any of the ~80 available
>subclasses.
> TreeTable treeTableViewOfMyMetadata = metadata.asTreeTable();
> TreeTableFormat format = new TreeTableFormat(myLocale, myTimezone);
> String s = format.format(treeTableViewOfMyMetadata);
>
>
>
> Martin
>