desise format for vocabularies

[Paul Harrison]

> On 2 Oct 2024, at 17:14, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> 
> On Tue, 1 Oct 2024, Paul Harrison via semantics wrote:
> 
>> 
>>> On 1 Oct 2024, at 10:37, Markus Demleitner via semantics <semantics at ivoa.net> wrote:
>>> 
>>>> I feel that it would be nice if the desise format did in fact make
>>>> these keys mandatory and boolean in type to reduce the amount of
>>>> interpretation code needed by clients.
>>> 
>>> Well... if you look at 3.2.2, the pattern for "see if a term is
>>> deprecated" is (IMHO) simply:
>>> 
>>> "deprecated" in voc["terms"][term]
>>> 
>>> (ok, that's for Python, but a is-key-present test ought to be rather
>>> straightforward in any language/library expressive enough to make
>>> working with JSON fun).  The alternative you propose
>>> 
>>> voc["terms"][term]["deprecated"]
>>> 
>>> does not seem so dramatically simpler to me than that to justify a
>>> breaking change in desise.
>> 
>> This is really a difference between the statically typed and not statically typed approach. In the statically typed approach
>> you might create an object with members and initially think that the deprecated member be typed as boolean from its description - however, when you try instantiate this object from theJSON using your favourite JSON library you get a type error - so then you realise that it should be typed as a string, but then you end up with code that is checking nulls which is never that nice. However, it is liveable with. So in Python there is really no difference in the client code complexity/ elegance between the two, but in Java there is.
> 
> As a fan of static typing I'm happy with the way it's been done.
> Deserialising the JSON into a suitable java Object didn't seem painful.
> 
> One other benefit of coding flags by presence of a key rather than
> by a required True/False value for a mandatory key is extensibility:
> if we decide one day we need another false-defaulting flag in there
> it can be introduced in a smooth and backwardly compatible way,
> rather than worrying about desise-v1 JSON objects lacking keys
> that are mandated by desise-v2.
> 
> But anyway - let's not change it unless there's a pretty persuasive
> reason.
> 

As I said in the previous message, I think that “correcting" desise is not worth the disruption. However, I am trying to emphasise that this is a pattern that we should avoid in future as there is a push towards JSON. As the deprecated key is string typed then is

“deprecated” : null

also a true value? 

Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20241003/e15a563e/attachment.p7s>