<div dir="ltr"><div>All,<br><br></div>Sorry for being a thorn about this, I&#39;m just concerned that an important detail might be getting lost.<br><br><div><div><div><div class="gmail_extra">Correct me if I&#39;m wrong, but I believe the UML EnumerationLiteral has no restriction on the value.<br></div><div class="gmail_extra">All of the examples which fail the vo-dml validation are fine by UML standards.<br><br></div>You asked:<br><div class="gmail_extra">&gt;Why all-caps for enumliteral names?<br></div><div class="gmail_extra">  Why not.. <br><div class="gmail_extra">  Once vo-dml imposes a restriction to the value (name), it stops being the literal, and becomes a code representing the literal.  vo-dml could impose an all-caps restriction as easily as the  VODMLName pattern.  The form of the restriction is arbitrary.  As such, the value of that field becomes arbitrary.  As you say, a simple list of values would do.<br></div><br></div><div class="gmail_extra">So, where then, is the literal?<br><br>The purpose of vo-dml is..<br>&gt;Which is primarily annotation of data sets for use by software.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">which, I agree, only requires the &#39;name&#39;.  So, from that perspective:<br></div><div class="gmail_extra">   (please forgive the ad-hoc serialization here)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">&lt;GROUP name=SomeObject vodml-id=&quot;model:package.SomeObject&quot; &gt;<br></div><div class="gmail_extra">    &lt;PARAM datatype=&quot;char&quot; name=&quot;att1&quot; vodml-id=&quot;model:myTypes.SpectralBand.XRAY&quot; value=&quot;X-Ray&quot; arraysize=&quot;*&quot;&gt;<br>       &lt;DESCRIPTION&gt;<span>&quot;0.1 Angstrom &lt;= wavelength &lt;= 100 Angstrom&quot;</span>&lt;/DESCRIPTION&gt;<br><br>    &lt;PARAM datatype=&quot;char&quot; name=&quot;att2&quot; vodml-id=&quot;model:myTypes.SpectralBand.XRAY&quot; value=&quot;bob&quot; arraysize=&quot;*&quot;&gt;<br>       &lt;DESCRIPTION&gt;<span>&quot;0.1 Angstrom &lt;= wavelength &lt;= 100 Angstrom&quot;</span>&lt;/DESCRIPTION&gt;<br><br></div><div class="gmail_extra">Both would be valid mappings from the user since they are both tagged with the proper vo-dml EnumLiteral even<br></div><div class="gmail_extra">though they have different values.<br><br></div><div class="gmail_extra">But, for a model aware, but not vo-dml savvy piece of software, it would not be possible to instantiate the <br></div><div class="gmail_extra">proper SpectralBand enumeration instances.  This requires the literal to be defined in the model and used here.  <br>In the vast majority of cases, the literal == code, but not always.  Maybe another example.. if/when we model Observation better, and <br></div><div class="gmail_extra">include observatory location, may have country enum:  <br>   Country.USA = &quot;United States&quot;,<br></div><div class="gmail_extra">   Country.NZ    = &quot;New Zealand&quot;<br></div><div class="gmail_extra">   Country.PNG = &quot;Papua New Guinea&quot;<br><br></div><div class="gmail_extra">The difference between this and other types, is that the EnumLiteral vo-dml tag should be associated with one and only 1 value (the literal),<br></div><div class="gmail_extra">which is specified by the model.  If the name is arbitrary, then this must be provided by another field.. label|title.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">So, maybe the label isn&#39;t needed in vo-dml, just at the model level.<br></div><div class="gmail_extra">I could define the XRAY EnumerationLiteral and tag it with a label=&quot;X-Ray&quot; and those reading the PDF will get this information.  <br>But it wouldn&#39;t be conveyed to the HTML description produced by the xslt scripts, because it is not a recognized field of the vo-dml element.<br><br></div><div class="gmail_extra">Enough for now.<br></div><div class="gmail_extra">Mark<br><br><br></div></div></div></div></div>