UCDs in SpectrumDM
Andrea Preite Martinez
andrea.preitemartinez at iasf-roma.inaf.it
Sat Jun 23 13:19:31 PDT 2007
as you have the right to say:
> I guess I don't feel that
> (and similar) are 'cumbersome' - I find them much easier
> to understand than extra custom-crafted UCDs like ..perWave.
> I guess I would like a reason based on the standard that it's not right,
> rather than just 'Andrea doesn't like it'...
I think I have the same right to say what I said: that, although
perfectly legal, I see the risk of building a cumbersome expression if
one adds other qualifiers/modifiers.
> I'm a bit concerned that you give me all this input now
> at/after the end of the RFC period, we were hoping to get approval
> for Spectrum
> at the July 15 exec - if we need to add all these new UCDs, does this
> mean we have to wait for a new update to the words list to be approved
> before Spectrum can go to approval? (Plus, of course, the time required
> for all the implementers to change their implementation, since
> we've published
> essentially the current list of Spectrum UCDs over a year ago and
> everyone is using
> them - this mostly is important for the Flux.Value cases).
No, my personal point of view is that the DM WG does not have to wait
for a new update to the word list. Remember that the present version
of the doc (at pag.23) already proposes some (+ the change of role of
pos.eq, not yet standard!).
I don't se why the EXEC should not approve a Rec proposing some
modifications/additions to the current version of another standard:
btw, they are going to approve Search-by-Cone, where old UCD1 are
still used, based on a motivation similar to what you are expressing
above (implementers should change their implementations).
> I hope other sci-ucd members will comment.
I agree with you!
Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it
Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242452
I-00133 Roma Cell. :+39.318.104.22.1683
More information about the semantics