<div dir="ltr"><div><div><div><div><div><div><div><div>All,<br><br></div>chair hat on:<br></div>  I&#39;ve certainly been the most vocal on this topic.. but don&#39;t want to gum up the works.  I&#39;m going to summarize my position here, then step back a bit.  I suggest we give the topic a week or so for other opinions/discussion to take place, then select a course of action (say ~ 1/22 or 1/29) so Gerard can make whichever adjustments need to be made.<br> <br>chair hat off:<br>&gt; Mark, Arnold, any problems simply making the &#39;name&#39; of the enumliterals conform to these rules?<br><br></div><div>Basically yes, I don&#39;t think this is what we want.<br><br>This option means that all vo-dml compliant models must only use EnumerationLiterals which conform to the vodml-id pattern &#39;[a-zA-Z_][\w_]*&#39;.<br></div><div>Since the value is directly tied to the definition of the EnumerationLiteral, these are the values which data providers MUST give when representing these literals.<br><br></div><div>Generally this is not an issue since enumerations are typically a simple value set, but in the DatsetMetadata model, we already have 4 examples which violate this pattern.<br></div><div>   SpectralBand:<br>     &quot;X-ray&quot;<br>     &quot;Gamma-ray&quot;<br><br></div><div>   CreationType:<br></div><div>     &quot;catalog extraction&quot;<br></div><div>     &quot;spectral extraction&quot;<br><br></div><div>I really can&#39;t speculate what things might be enumerated in future models, but some examples of things which would not pass this pattern test:<br></div><div>  + anything with multiple words<br></div><div>        o CreationType above<br></div><div>        o Country:  &quot;Papua New Guinea&quot;<br></div><div>        o Institute: &quot;Centre de Données astronomiques de Strasbourg&quot;<br></div><div>        o StellarClass: &quot;Brown Dwarf&quot;, &quot;Red Giant&quot;, &quot;Neutron Star&quot;, &quot;X-ray Binary Star&quot;</div><div><br>  + anything containing &#39;.&#39; or &#39;-&#39; or non-word character, or starting with a number<br></div><div>       o see SpectralBand above<br></div>       o Quasar: &quot;SDSS J1004+4112&quot;, &quot;QSO B1359+154&quot;, &quot;3C 273&quot;,  &quot;PKS 0637-752&quot;<br></div><br></div>Again, I&#39;m not suggesting any of these would be enumerated, only giving the flavor.<br>All of these would be valid EnumerationLiterals in standard UML, but not be compliant vodml EnumLiteral-s.<br></div>They would need to be converted to a vodml compliant form:<br></div>  + using CamelCase <br></div>        &quot;XRay&quot;, &quot;CatalogExtraction&quot;, &quot;PapuaNewGuinea&quot;, &quot;CentreDeDonneesAstronomiquesDeStrasboug&quot;, etc<br><div><div><div><br>  + others more tricky<br></div><div>        &quot;SDSS_J1004p4112&quot;, &quot;PKS_0637d752&quot;<br><br></div><div>  + not sure what we&#39;d do with a numeric.. perhaps just a sequence [&quot;A&quot;, &quot;B&quot;.. ] <br></div><div><br></div><div>Whatever the mechanism, most of these would still understandable as far as the tag goes.<br></div><div>My concern is that since EnumerationLiterals are unique in that the value is directly tied to the <br></div><div>literal, these are the values data providers would have to give in query responses, and data products<br></div><div>when referencing these literals.  I don&#39;t think that is good.<br><br></div><div>The second option proposed would<br></div><div>  + allow the definition of a vodml pattern compliant name<br></div><div>  + and associate it with the real-world literal value (lable|title|fullName)<br><br></div><div>Which I think is better.<br><br><br></div><div><br><div><div><div><div><div class="gmail_extra"><div class="gmail_quote"><br></div></div></div></div></div></div></div></div></div></div>