Check structure of class_definition

[AntoineGautier]

From the JSON schema at https://github.com/lbl-srg/modelica-json/blob/master/schema-modelica.json#L7-L10 class_definition should be an array.
However, when translating a Modelica file with local class definitions (such as GreaterNoHysteresis within Buildings/Controls/OBC/CDL/Reals/Greater.mo) the corresponding JSON output has the following structure, where class_definition is parsed as a non-array object:

In addition, the class name lookup fails for such classes.

utilM2j.searchPath(
    ['GreaterNoHysteresis'], 
    'Buildings.Controls.OBC.CDL.Reals', 
    '/home/reituag/tmp/modelica-buildings/Buildings/Controls/OBC/CDL/Reals/GreaterThreshold.mo') // returns []

[AntoineGautier]

@JayHuLBL Can you check if this is a bug?

[JayHuLBL]

@AntoineGautier
In the schema, I would suggest to change the line 171

modelica-json/schema-modelica.json

Line 171 in f0b714b

"class_definition": {

, to become as below and have the same definition as class_definition but change the type to object.

"element_class_definition": {
            ...
          },

[AntoineGautier]

I wonder whether the following modifications would not be a better match with the grammar.

Replace the definition of class_definition:

modelica-json/schema-modelica.json

Line 8 in f0b714b

"class_definition": {

with:

  "definitions": {
    "stored_class_definitions": {
      "description": "Stored class definitions",
      "type": "array",
      "additionalItems": false,
      "items": { "$ref": "#/definitions/class_definition" }
    },        
    "class_definition": {
      "description": "Class definition",
      "type": "object",
      "required": [
        "class_prefixes",
        "class_specifier"
      ],
      "additionalProperties": false,
      "properties": {
        "final": {
          "type": "boolean"
        },
        "encapsulated": {
          "type": "boolean"
        },
        "class_prefixes": {
          "type": "string"
        },
        "class_specifier": {
          "$ref": "#/definitions/class_specifier"
        }
      }
    }

This way:

• stored_class_definitions is mapped to stored-definition : { [ final ] class-definition ";" } from the grammar (except that I don't know how to handle the optional final keyword, but this is an issue with the current schema as well),
• class_definition is no more an iterable as it currently is — which is inconsistent with the grammar,
• the property class_definition within element_list remains unchanged: "class_definition": { "$ref": "#/definitions/class_definition" }.

As part of this issue, is it also possible to fix utilM2j.searchPath so that it can find short class definitions from element_list, public_element_list, protected_element_list as well?

[JayHuLBL]

@AntoineGautier Thanks for the suggestion. I will update it accordingly.

[JayHuLBL]

@AntoineGautier
The JSON output of the GreaterNoHysteresis can be found in the Greater.json and thus the GreaterNoHysteresis is in Buildings/Controls/OBC/CDL/Reals/Greater.mo. The util.searchPath is to find the .mo file that has the instantiated class, so the output JSON files have the same folder structure as the .mo files.
Are you expecting to extract the JSON output of an instantiated class? It could be exactly 1-to-1 match the .mo file, or one section of the JSON output of a bigger .mo file.

[AntoineGautier]

@JayHuLBL In the case of short class names, I expected util.searchPath to return the path to the mo file containing the short class definition. However, in this case util.searchPath returns an empty array.
This is understandable, as this function is primarily intended to retrieve the file paths of all instantiated classes, and in the case of a short class definition, the file path is actually identical to that of the class where the short class is instantiated (which is already included as the class has already been parsed).
Knowing this, there is no more issue related to util.searchPath.