[vodml] EnumLiterals and vodml-id

CresitelloDittmar, Mark mdittmar at cfa.harvard.edu
Mon Jan 11 23:00:11 CET 2016


All,

How about 'label'?  Though I have no strong opinion one way or the other.

I think the idea would be to present a 'real-world' equivalent to the token
which would be used for user interaction (eg: display).

In the DatasetMetadata instances
  SpectralBandType
    + "X-ray"
    + "Gamma-ray"

can move to
  SpectralBandType
    + name="xray"  [title|label]="X-ray"
    + name="gammaray"  [title|label]="Gamma-ray"

so the name can conform to a pattern, but still define a familiar
translation.
A similar thing could be done with the CreationType tokens.

>>Mark, Arnold, any problems simply making the 'name' of the enumliterals
conform to these rules?

I do think having the free-form option is important.  The values of these
enums are rooted in
the various standards (ObsCore, ResourceMetadata, VODataService).  I think
there is some
flexibility for making viable tokens, but would like to keep the full spec.

Mark



On Mon, Jan 11, 2016 at 4:33 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi DM,
>
> On Sun, Jan 10, 2016 at 01:14:46PM +0000, Gerard Lemson wrote:
> > I think one obvious solution might be to add a 'fullName' attribute
> > (or 'title'? I'd be open to alternative name) to EnumLiteral that
>
> I guess it'd be "title" for me if I had to choose.  But what use
> would it be (i.e., how is Software expected to use this title)?
>
> > The other, more straightforward solution is to restrict
> > enumliterals to the pattern for VODMLName.
> > I actually slightly prefer this solution and not only because it is
> > simpler. Enumerations are primitive types with a discrete set of
>
> With the caveat that I have no implementation experience here (and
> the judge on gut feeling and conjecture), I'm fairly sure this is far
> preferable; if those enums are going to be mapped to enums in
> languages that have them, the literals must follow these languages'
> identifier rules.  Since neither LISP nor FORTH are the mainstream
> languages we target, we had better have a restrictive pattern that
> actually works with identifiers in C, Java and Python.  Which happens
> to be what this alternative does.
>
> Perfect with me.
>
> Cheers,
>
>        Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20160111/c5773415/attachment.html>


More information about the dm mailing list