<div dir="ltr"><div class="gmail_default" style="font-size:small">Laurent: thanks for the example showing clearly the choice being made:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">>We can see that the point of contention with Markus is limited to a 
small sequence: 5.1: <br></div><div class="gmail_default" style="font-size:small">>using VODML/NAME or VODML/VOMDL-ID to build MIVOT 
roles. <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This made me think about how name and vodml-id are related so I went and looked in my own CAOM vodml to see if the name was always the "end" of the id. It turns out generally yes and that make sense to me (because who wants to come up with two names for the same thing - one is hard enough).  I did find a case in the CAOM vodml where they were not and it's valid (schematron validation). That's fine by itself, but...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">then I noticed that two attributes of the class had the same name (because I added a new attribute by copying and while I changed the vodml-id I missed changing the name, so that VODML essentially says that a object has two attributes with the same name. I wrote a test case, made sure I had the latest vodml xsd and sch files, and that validation was working (if I make the vodml-id values the same, validation fails).<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">test case attached.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">thoughts? <br></div><div class="gmail_default" style="font-size:small"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 17 Feb 2023 at 00:22, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear DM, again,<br>
<br>
On Thu, Feb 16, 2023 at 06:28:27PM +0100, Markus Demleitner wrote:<br>
> But on the other hand, no urget use case is actually waiting for this<br>
> to become REC (or is one?), and given we're betting our coordinate<br>
> annotation on it, we can at least wait with REC until we successfully<br>
> exchange a 6-parameter astrometric solution with it and do an epoch<br>
> propagation, with one client and two services implemented by three<br>
> different people.  I'm volunteering to be one on the server side, but<br>
> I'll need help making sense of MCT.<br>
<br>
Oh, just to prevent misunderstandings: I still stand by my request<br>
from the RFC as Semantics chair (i.e., with my responsibility to<br>
evaluate due process):<br>
<br>
  But the actual promise of the whole DM thing is that I can see<br>
  whether instances actually match the constraints set by the VODML<br>
  -- is there anything like that? Again, I think I really cannot vote<br>
  for this until there is at least a credible prototype for such a<br>
  validator, because without it, I can already predict we will have<br>
  almost only invalid annotations given the complexity of this spec.<br>
<br>
I'm serious about it.  For one, the Registry experience is clear:<br>
Documents not validated are almost certainly invalid; at least I<br>
never got a VOResource document right the first time, there was<br>
always something that the validator found fault with.  And that's for<br>
the Registry model, which compared to MIVOT+out models is compact and<br>
straightforward.  This means:<br>
<br>
  *We cannot implement against these standards without an instance<br>
  validator*.<br>
<br>
Another important aspect: trust me as a standards author who has made<br>
a lot of mistakes (the most recent (embarrassing) instance:<br>
<<a href="https://wiki.ivoa.net/twiki/bin/view/IVOA/DALI-1_1-Erratum-1" rel="noreferrer" target="_blank">https://wiki.ivoa.net/twiki/bin/view/IVOA/DALI-1_1-Erratum-1</a>>).<br>
Writing a validator is an excellent opportunity to spot mistakes,<br>
contradictions, missing considerations on corner cases, plain<br>
stupidity (as in my DALI 1.1 Erratum 1 case) and so on.  Writing a<br>
validator is *really* an extremely valuable thing.<br>
<br>
Now, on the RFC page, Laurent says:<br>
<br>
  Building a tool than can validate MIVOT annotations against the<br>
  model structure is feasible but out of reach for the resources we<br>
  have.<br>
<br>
Frankly: to me this means "the standard(s) is/are too complicated to<br>
implement".  If that really is what the RFC has turned up, then let's<br>
simplify the standard so it can be implemented with the resources we<br>
have.  There is no point specifying something we cannot implement.<br>
<br>
Here's an offer: I volunteer to write a validator of the basic<br>
subset of MIVOT that you hint at somewhere in the document (INSTANCE,<br>
ATTRIBUTE, a subset of COLLECTION) *if* the rest then is taken out of<br>
MIVOT 1.0; we can re-introduce it later when we have a solid<br>
foundation to build on.<br>
<br>
Also on the RFC page, Laurent says:<br>
<br>
  The question of instance validator is also difficult to solve<br>
  because we have to define what is a valid instance of the model.<br>
  vo-dml provides formal xml description of data models but what<br>
  about instances of these data models ? The only way to create such<br>
  instances is via the automatic generation of .xsd xml schema for<br>
  each vo-dml consistenet datamodel.<br>
<br>
The part about XML schema is, I think, not true.  VO-DML makes clear<br>
validity requirements.  These can be tested without assuming any<br>
specific serialisation. You de-serialise whatever you get (in this<br>
case: MIVOT; in some other: XML schema files) and *then* validate<br>
these instances against whatever is in VO-DML.<br>
<br>
Writing something that does this is exactly what I'm offering (for a<br>
small subset of the current draft).  Let me quote DocStd 2.0:<br>
<br>
  After a suitable review and trial period, the chair of the Working<br>
  Group may promote the Working Draft to a *Proposed Recommendation*<br>
  [...] When applicable, the Working Group should be able to<br>
  demonstrate two interoperable implementations of *each feature*,<br>
  and validation tools should be available.<br>
<br>
(emphasis mine); I think we're in agreement that the implementation<br>
clause is applicable here.  True, a bit later it says:<br>
<br>
  In its final review the TCG may agree to waive these requirements<br>
  if there are extenuating circumstances.  If the TCG does not agree<br>
  to waive the requirement regarding interoperable implementations<br>
  and/or availability of validation tools, but there are otherwise no<br>
  outstanding issues or unresolved problems, the final decision on<br>
  promotion rests with the Executive Committee.<br>
<br>
Me, I think in this case we have the exact opposite of "extenuating<br>
circumstances".<br>
<br>
Sorry to be stubborn here, but we just *have* to learn from the STC 1<br>
disaster -- the way I see things, we're still recovering from it in<br>
many ways.<br>
<br>
        -- Markus<br>
</blockquote></div>