[p3t] Draft documents demonstrating standards layout

[Russ Allbery]

Paul Harrison <paul.harrison at manchester.ac.uk> writes:
> On 26 Aug 2024, at 06:18, Dave Morris via p3t <p3t at ivoa.net> wrote:

>> We should try to avoid referring to the overall goal as the 'JSON
>> network protocol' - that is what P3T should be trying to avoid. If we
>> bind too strongly to JSON we are in danger of repeating the mistakes of
>> 20 years ago when we bound our standards to XML, WSDL and SOAP.

> Near the start of these conversations, I tried to point out that the
> IVOA already has a standard way of describing the “schema” part of these
> interface definitions - i.e VO-DML - if the data models associated with
> a service are described in VO-DML, then in another 20 years time when
> some other serialisation format is fashionable, then the VO-DML tooling
> can just be altered to emit the schema for that serialisation, without
> having to re-author the data model source, and obviously the more data
> models there are the more advantageous this is.

Right, this was one of the sources of existing data types that this work
needed to be reconciled with.  (The others are UCD, DALI, and VOTable.
There are probably others that I'm missing.)  I only hadn't looked at that
because I didn't have time yet.  I wanted to get a raw framework out
first, and this was one of the details I wanted to go back and revisit.

I've taken a brief look this morning.  There's a lot of material in the
VO-DML standard, so I'll have to go back to it later for a longer look.
I had a few quick questions based on that initial look (and apologies if
these are clearly answered already and I just missed them):

1. The existing document covers a lot of the ground that I think we'll
   need (boolean, integer, real, datetime, string, enum) and a few things
   I hadn't started thinking about (complex), but the primitive types by
   design don't include valid ranges or precision information.  It looks
   like ranges are handled with a Constraint element (and maybe precision
   as well?).  Are there already data types for integers and reals defined
   that conform to the sorts of constraints we'll need for interoperable
   wire protocols (IEEE 64-bit floating point numbers, for example, which
   impose multiple restrictions on both range and precision)?

2. The definition of a string needs to define what a "character" is for
   interoperable protocols.  How would we go about doing that?  Is that an
   update to VO-DAL, or a specialization of the primitive type defined
   there?  Similarly, datetime doesn't specify precision or time standard,
   which we would need to nail down.

3. The VO-DML specification makes reference to a lot of useful composite
   types like SkyCoordinate, but they're not in the HTML page linked from
   the VO-DML 1.0 document page.  Is there a registry somewhere else of
   composite types like that which have already been defined?

4. The VO-DML document is extremely XML-heavy.  It looked like every new
   type defined in that framework is accompanied by an XML schema.  Is
   this required for new types?  I think we only have as a goal that
   implementers need not know XML, not that specification authors need not
   know XML, but the latter would be a desirable property from my
   perspective since I think it will be limiting when we try to find
   enough resources to write down good specifications.

I think having a shared data type registry is an excellent idea, and I'd
like to use it heavily.  I would be inclined to register a reusable data
type with a name as soon as we have a need for the same data type in two
different standards, so ideally we should make it very easy to register
new ones, which if I understand correctly is part of the goal of the
VO-DML work.

What I'm hoping for as output is something like an IANA registry page that
includes all of the registered data types and their specifications in
human-readable HTML, and without requiring publication of a standards
revision in order to add a new data type.  If I understand VO-DML
correctly, that's in close alignment with its goals, and maybe I'm just
missing where that registry page is currently?

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>