MIVOT: fully qualified attribute names

[Markus Demleitner]

Dear DM, again,

On Thu, Feb 16, 2023 at 06:28:27PM +0100, Markus Demleitner wrote:
> But on the other hand, no urget use case is actually waiting for this
> to become REC (or is one?), and given we're betting our coordinate
> annotation on it, we can at least wait with REC until we successfully
> exchange a 6-parameter astrometric solution with it and do an epoch
> propagation, with one client and two services implemented by three
> different people.  I'm volunteering to be one on the server side, but
> I'll need help making sense of MCT.

Oh, just to prevent misunderstandings: I still stand by my request
from the RFC as Semantics chair (i.e., with my responsibility to
evaluate due process):

  But the actual promise of the whole DM thing is that I can see
  whether instances actually match the constraints set by the VODML
  -- is there anything like that? Again, I think I really cannot vote
  for this until there is at least a credible prototype for such a
  validator, because without it, I can already predict we will have
  almost only invalid annotations given the complexity of this spec.

I'm serious about it.  For one, the Registry experience is clear:
Documents not validated are almost certainly invalid; at least I
never got a VOResource document right the first time, there was
always something that the validator found fault with.  And that's for
the Registry model, which compared to MIVOT+out models is compact and
straightforward.  This means:

  *We cannot implement against these standards without an instance
  validator*.

Another important aspect: trust me as a standards author who has made
a lot of mistakes (the most recent (embarrassing) instance:
<https://wiki.ivoa.net/twiki/bin/view/IVOA/DALI-1_1-Erratum-1>).
Writing a validator is an excellent opportunity to spot mistakes,
contradictions, missing considerations on corner cases, plain
stupidity (as in my DALI 1.1 Erratum 1 case) and so on.  Writing a
validator is *really* an extremely valuable thing.

Now, on the RFC page, Laurent says:

  Building a tool than can validate MIVOT annotations against the
  model structure is feasible but out of reach for the resources we
  have.

Frankly: to me this means "the standard(s) is/are too complicated to
implement".  If that really is what the RFC has turned up, then let's
simplify the standard so it can be implemented with the resources we
have.  There is no point specifying something we cannot implement.

Here's an offer: I volunteer to write a validator of the basic
subset of MIVOT that you hint at somewhere in the document (INSTANCE,
ATTRIBUTE, a subset of COLLECTION) *if* the rest then is taken out of
MIVOT 1.0; we can re-introduce it later when we have a solid
foundation to build on.

Also on the RFC page, Laurent says:

  The question of instance validator is also difficult to solve
  because we have to define what is a valid instance of the model.
  vo-dml provides formal xml description of data models but what
  about instances of these data models ? The only way to create such
  instances is via the automatic generation of .xsd xml schema for
  each vo-dml consistenet datamodel.

The part about XML schema is, I think, not true.  VO-DML makes clear
validity requirements.  These can be tested without assuming any
specific serialisation. You de-serialise whatever you get (in this
case: MIVOT; in some other: XML schema files) and *then* validate
these instances against whatever is in VO-DML.

Writing something that does this is exactly what I'm offering (for a
small subset of the current draft).  Let me quote DocStd 2.0:

  After a suitable review and trial period, the chair of the Working
  Group may promote the Working Draft to a *Proposed Recommendation*
  [...] When applicable, the Working Group should be able to
  demonstrate two interoperable implementations of *each feature*,
  and validation tools should be available.

(emphasis mine); I think we're in agreement that the implementation
clause is applicable here.  True, a bit later it says:

  In its final review the TCG may agree to waive these requirements
  if there are extenuating circumstances.  If the TCG does not agree
  to waive the requirement regarding interoperable implementations
  and/or availability of validation tools, but there are otherwise no
  outstanding issues or unresolved problems, the final decision on
  promotion rests with the Executive Committee.

Me, I think in this case we have the exact opposite of "extenuating
circumstances".

Sorry to be stubborn here, but we just *have* to learn from the STC 1
disaster -- the way I see things, we're still recovering from it in
many ways.

        -- Markus