Replies: 1 comment 1 reply
-
|
On Fri, Dec 15, 2023 at 09:22:03AM -0800, Paul Harrison wrote:
The type system is sort of broken in that there is no "value" in
quantity only a possible unit - this does have implications when
Quantity is used in other models (e.g. coords).
+2000. I've always bemoaned that.
(not to mention that I'd *really* have liked if this whole thing had
just said "we're pointing to VOTable PARAMs and thus don't mention
unit, ucd, and whatever at all; if you really need to annotate
something other than VOTable, then do a FIELD/PARAM equivalent for
your own format and do the VO-DML binding based on that).
[But I really shouldn't be here...]
|
Beta Was this translation helpful? Give feedback.
-
|
I am looking at this from a whole different use case for the DM - It is an even bigger pain when code generating into OO languages - I realised that I have put in some fragile heuristics to accommodate what is happening in Quantity.... It could probably be "regularised" with subsetting (although there would also need to be some general abstract primitive) - In the end I think that for each language representation there probably have to be hand written versions of the Base IVOA model anyway - I think that my comment was more directed at the design of some of the child models that might have "empty" abstract base classes - they are not much practical use |
Beta Was this translation helpful? Give feedback.
-
The type system is sort of broken in that there is no "value" in quantity only a possible unit - this does have implications when Quantity is used in other models (e.g. coords).
Within the way that typing is used in vo-dml, there should probably be an abstract value primitive that could be put in here.
This exemplifies the difference between what a Data Model should specify and what a conceptual Domain model - we "know" conceptually that a "Quantity" should have a value - however in data models we should make that explicit.
Beta Was this translation helpful? Give feedback.
All reactions