IVOA VOTable signature issue

[Markus Demleitner]

Hi Carlos,

On Thu, Mar 30, 2017 at 12:09:19PM +0100, Carlos Rodrigo wrote:
> We have multi-resource notables in  datalink, don't we?

Not in, but with datalink.  With datalink in-DAL-response
descriptors, you could indeed have the situation that there's

<RESOURCE type="result">
  ...
</RESOURCE>

<RESOURCE type="meta">
  ...
</RESOURCE>

Now, while I'd have a slight preference for the standardID INFO as a
child for VOTABLE as well if there weren't the prior art I had
forgotten about as well, I'd say the in-RESOURCE INFO still works
in such a situation because these would be predictably found by

RESOURCE[@type="result"]/INFO[@name='standardID' && @value='ivo://whatever']

In the example above, it works because regardless of the datalink
resource, this still is an SSA/SIA/whatever response and should be
treated as such.

The xpath is also, IIRC, guaranteed of cardinality 0..1 as DALI (or
someone else) guarantees there's only one result resource.

The result of a datalink service proper (that would need to be
treated as a datalink document) would again have the above structure:

<RESOURCE type="result">
  <INFO name="standardID" value="ivo://ivoa.net/std/datalink"/>
  ...
</RESOURCE>

So, I'm not exuberant, but reasonably happy with this.  While writing
this, I noticed we should perhaps add a footnote or something with
the implementation note that IVOA identifiers are case insensitive
and thus need to be compared with extra care.

Case-insensitivity is an extra pain with xpath version 1 (but then
you're guaranteed it's ASCII only [1]), but there you go.  Ceterum
censeo case-insensitivity requirements in standards are the root of
17.4% of all interoperability problems.  Let's not have them any more.

        -- Markus


[1] %-encoded ASCII characters are not a problem in ivoids since IVOA
identifiers forbids %-encoding ASCII letters.  Ha!