vo-dml in votable

[Patrick Dowler]

On 09/03/15 04:39 AM, Laurino, Omar wrote:
> At this point I believe both solutions have strengths and drawbacks. One
> solution (only one TYPE) puts less burden on the server side, but more
> on the client. The other (more than one TYPE allowed) puts less burden
> on the client and more on the server side.

If I grok this correctly, declaring just the actual (leaf) type is 
required and the definitive declaration of the inheritance tree is in a 
(sequence of) vo-dml documents that define the model. In theory, one 
could load each document in turn and lookup the parent classes to build 
the tree...

This reminds me of Java class-loading where the jvm loads each parent 
class in turn all the way up to the root. Sure it just magically happens 
in java (.net, etc) but the principle is the same and when you use 
reflection to examine the the hierarchy you have to step up one class at 
a time to see the declared fields/methods.

TL;DR I guess I'm saying that the vo-dml documents contain the 
definitive inheritance hierarchy and additional type(s) in a votable 
document should be thought of as an optimisation to avoid loading and 
parsing vo-dml.... and as an optimisation that metadata in the votable 
could be inconsistent with the declared models. I'm not saying it isn't 
a valuable optimisation, but it's worth seeing it that way.

my 2c,

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)