DM Workshop wrap-up

[Mark Taylor]

Tom, Gerard et al.,

TL;DR: scoping rules could be drawn up to accommodate
       one-VODML-element-per-document in most cases,
       without precluding other possibilities

For the common case in which one VODML element applies to a linked
set of tables, yes an expectation of where that VODML should go
makes sense.  I certainly wouldn't want the niche topcat session-save
use case I mentioned to drive the design or disrupt what would
otherwise be the best arrangement for providers and consumers.

But maybe we could have something that serves both purposes by
talking about relative arrangements in a host document.
A couple of possibilities spring to mind.

(1) Require a maximum of one VODML element within a given scope,
where the scope may be (and typically is) the whole VOTable
document, but is permitted to be an ancestor element.

The scope of a VODML element in that case should probably be
the VODML element's parent RESOURCE and that parent's siblings
(as well as all their descendents) which would allow e.g.
a single scope document like:

   VOTABLE
     RESOURCE
       VODML
     RESOURCE
       TABLE
       TABLE

or a potentially multiple-scope document:

   VOTABLE
     RESOURCE
       RESOURCE
         VODML
       TABLE
       TABLE
     ...

It would also allow

   VOTABLE
     RESOURCE
       TABLE
       TABLE
       VODML

which could get away with a somewhat simpler scope definition
"the scope of a VODML element is all descendents of its parent resource",
but as noted by Gerard, the existing VOTable schema puts the VODML
after any tables in a resource not before, so that may be no good.
That could be amended (1b) by a minor change to the RESOURCE content
model; since it doesn't bring in any linkage to VODML as such I wouldn't
object to that per se, but I don't know if it's worth the effort.

(2) A more rigid alternative would be to say that the VODML-bearing
RESOURCE applies to its sibling TABLE-bearing resource, allowing
single VODML documents:

   VOTABLE
     RESOURCE
       VODML
     RESOURCE
       TABLE
       TABLE

or potentially multiple-VODML documents:

   VOTABLE
     RESOURCE
       RESOURCE
         VODML
       RESOURCE
         TABLE
         TABLE
     ...

Whatever is decided: some example arrangements in the standards text
of where a VODML element goes in the most common case(s) will
go a long way to clarifying how to go about this in practice.

Mark

On Wed, 21 Jul 2021, Tom Donaldson wrote:

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

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/