<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 29 Aug 2024, at 18:59, Russ Allbery <eagle@eyrie.org> wrote:</div><br class="Apple-interchange-newline"><div><pre style="caret-color: rgb(0, 0, 0); font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: sans-serif; white-space: pre-wrap; overflow-wrap: break-word;">My larger concern is that I am dubious that OpenAPI will prove to be
resilient against future changes to prevailing protocols and definition
languages any more than XML schemas were. gRPC does not use OpenAPI, for
example; it uses protobuf as its API definition language. I fear that
OpenAPI is a specification language for this one particular moment in
time, and in the future people will use something else, similar to how XML
schemas used to be common and now, although they still exist, they're less
widely used.
That said, designing a specification language is an immense amount of
work, and I don't want us to write our own either. We should use OpenAPI
today because that's what people use today. But I would like to have some
sort of semantic language specific to the IVOA, ideally one with a minimum
amount of additional formality so that it's easy to read and easy to
write, that nails down all the things that OpenAPI may leave ambiguous and
provides enough additional information that we can adapt our data types to
some new language that comes along later.
</pre><br class="Apple-interchange-newline"></div></blockquote></div><br><div>Designing a general purpose specification language is a lot of work - however, all we *need* is a language to describe</div><div>interfaces that follow IVOA patterns, so that it does not have to be that extensive. So for example when the </div><div>hypothetical IVOA interface language says for example “return error” it can be transformed into the IVOA pattern in OpenAPI that</div><div>expresses the way to return an error. So that a lot of the “detail” that makes OpenAPI complex is removed by having conventions.</div><div><br></div><div>Paul.</div><div><br></div></body></html>