DM Workshop wrap-up

[Gerard Lemson]

> > FWIW I personally think an explicit extension of the schema would be more
> appropriate.
> > The whole VO-DML mapping approach was explicitly designed for use in
> VOTable, as an implementation/evolution of the ideas underlying the utype
> attribute.
> > So that being explicitly part of the VOTable schema, even if only in an
> imported or included form, seems correct to me.
> > But if it is (again) important that VOTable should not be changed, including it
> in RESOURCE seems the right thing.
> 
> In general, I would say that avoiding interdependencies (as opposed to
> compatibility) between separable components is good practice.  In this
> particular case, VOTable is very mature, while this VO-DML syntax, while it has
> benefitted from a great deal of thought, hasn't had much confrontation with
> real-world use, and so I'm concerned that changes might be required in future.
> Protecting VOTable from possible fallout from that, especially in absence of
> material advantages from creating such a dependency, looks to me like a good
> plan.  From the point of view of VODML, that means it doesn't need to wait for
> a VOTable update in order to be ready for use.  But, I guess it's a decision for
> VOTable editors/Apps WG/TCG.
> 

Fair. And the proposed solution allows us to perform these experiments.
Thanks
Gerard