DM Workshop wrap-up

[Tom Donaldson]

Hi All,

I'm certainly content to take a pragmatic approach to this, but (or therefore) I do want to take a fairly careful look at the pragmatic impacts of the changes, and minimize impact on clients over the short to medium term.

Conceptually, I think the ability to add a specific candidate standard syntax (e.g., VODML) to VOTables is plenty to warrant a new VOTable version, perhaps even if the schema doesn't need to change at all.  That may give clients a specific way to partition their implementations into whether such content may even be present.  But it's also possible that not changing the version for now is more desirable for its flexibility, at least until we have something more concrete to say about the content.  I'm open to either approach at this point.  I do agree that we don't want a new VOTable version every time VODML syntax is tweaked.

Regarding putting constraints on where VODML may appear in a RESOURCE, Mark puts forward an interesting Topcat use case, and I do agree it would not be *that* hard for most clients to be flexible.  That said, prior to the RESOURCE-based proposal, we've only talked about a single VODML element, and at least in the prototype schemas I worked on in the past, it's location was quite fixed in the VOTable structure.  My suggestion was just to constrain the RESOURCE proposal to achieve the same predictability for clients, so that they don't need to error check that they got a surprise VODML element after the data for example. 

If the VODML option was implementable, then presumably some restrictions on the RESOURCE would also be.  If not, then we should discuss that too.  Supporting the Topcat use case may add scoping issues, but I'm guessing those are solvable.  If not, then it may be that the arbitrary flexibility in multiple nested RESOURCEs in VOTable that is more of the actual issue.

The situation I'm trying to avoid is one that comes up with some regularity, and that is where we allow too many ways to do the same thing, leaving the clients guessing a bit, thus often reducing interoperability, sometimes due to partial implementations based on the examples (which don't tend to exercise all the options).

Thanks,
Tom


On 7/21/21, 2:21 PM, "Mark Taylor" <m.b.taylor at bristol.ac.uk> wrote:

    External Email - Use Caution

    On Wed, 21 Jul 2021, Gerard Lemson wrote:

    > 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.

    --
    Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
    m.b.taylor at bristol.ac.uk          https://urldefense.com/v3/__http://www.star.bristol.ac.uk/*mbt/__;fg!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!hiQUB2-B-YqGyfYbkw8wVOhtGqtYTI6gPdjHsDiU8v73zBPeT-KXj1SJNVE9REQaZw$