Open enikao opened 3 months ago
We loose one use case, where someone want to store untyped JSON data in a model. The StructuredDatatype needs to have all its fields explicitly defined in the language definitions, a JSON property does not.
We first label the JSON
primitive type as deprecated in all implementations, then add support for the value types, and just before releasing 2024.1 we can remove JSON
entirely.
Do we really want to add a Deprecated Annotation to the M3 element?
Would it be work to define the Deprecated
Annotation as part of LionCore (version "2024.1
") itself?
Would it be work to define the
Deprecated
Annotation as part of LionCore (version "2024.1
") itself?
We could. The question is whether we want. To me it feels like the wrong place. You cannot sensibly use LW without String
, Node
, etc. However, you don't need to know about deprecation to use LW.
We could add the annotation to the builtins as well, but that doesn't solve the (de-)serialization of M2s-problem.
Oh sorry I misread your question, and answered it for builtins.
So we would allow an annotation to be used on the language that defines the annotation? Does not seem to simplify the implementation.
No, it doesn't... I guess we should just try to implement in all current reference implementations.
We remove Primitive Datatype
JSON
from builtins library (#9).Rationale: We add structured datatypes (#265). This should cover almost all use cases we envisioned
JSON
primitive datatype for. The one remaining (weak) use case would be: We already have some JSON data in our domain, and want to store it in the model.JSON
support in LionWeb would relieve this language from (de-)serializing that JSON data from/to the model. However, chances are we already have a JSON (de-)serializer if we're dealing with JSON data.We explicitly don't guarantee compatibility between different LionWeb versions (#130).
As a side-effect, this also tests what happens if we make such changes to the spec.