Azure / opendigitaltwins-dtdl

Digital Twins Definition Language
Creative Commons Attribution 4.0 International
466 stars 160 forks source link

Create reusable schemas for complex types #105

Open uriel-kluk opened 3 years ago

uriel-kluk commented 3 years ago

I would like to define only once an enum or an object and reuse it as a type.

Example

{
  "@context": "dtmi:dtdl:context;2",
  "@id": "dtmi:loglevel;1",
  "@type":"???ComplexType???",
  "schema": {
    "@type": "Enum",
    "valueSchema": "integer",
    "enumValues": [
      {
        "displayName": "Trace",
        "enumValue": 0,
        "name": "Trace"
      },
      {
        "displayName": "Debug",
        "enumValue": 1,
        "name": "Debug"
      },
      {
        "displayName": "Information",
        "enumValue": 2,
        "name": "Information"
      },
      {
        "displayName": "Warning",
        "enumValue": 3,
        "name": "Warning"
      },
      {
        "displayName": "Error",
        "enumValue": 4,
        "name": "Error"
      },
      {
        "displayName": "Critical",
        "enumValue": 5,
        "name": "Critical"
      }
    ]
  }
},

And then have an interface that uses the enum: Example:

  {
    "@context": "dtmi:dtdl:context;2",
    "@id": "dtmi:devicehealth;1",
    "@type": "Interface",
    "displayName": {
      "en": "Device Health"
    },
    "contents": [
      {
        "@type": "Property",
        "displayName": "Log Level",
        "name": "LogLevel",
        "schema": "dtmi:loglevel;1"
    },
      {
        "@type": "Telemetry",
        "displayName": "Trace",
        "name": "trace",
            "schema": {
              "@type": "Object",
              "fields": [
                {
                  "name": "TimeStamp",
                  "schema": "dateTime"
                },
                {
                  "name": "level",
                  "schema": "dtmi:loglevel;1"
                },
    },
briancr-ms commented 3 years ago

Thanks for bringing up this issue. Currently, DTDL v2 supports reusable types within an interface definition (by using the schemas property on Interface). See this section in the DTDL v2 documentation: https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/dtdlv2.md#interface-schemas.

However, this does not support "globally" reusable types or types defined outside of any interface, which is what you may be asking for. This is a feature we are interested in providing. We're not quite ready to share a design proposal on this, so I will leave this issue open until we get a proposal together to share.

Mateo-9 commented 3 years ago

Theoretically, the schemas are reusable, but actually they are not. When I tried to use it with Azure Digital Twins, my models cannot be uploaded because it says that the Enum Schema is defined in another interface. So they propose to copy the schema in every interface that needs it.

This is not useful like that, it is necessary to allow the creation of global schemas that could be reused by all the interfaces or schemas available to the descendants.

Thanks for bringing up this issue. Currently, DTDL v2 supports reusable types within an interface definition (by using the schemas property on Interface). See this section in the DTDL v2 documentation: https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/dtdlv2.md#interface-schemas.

However, this does not support "globally" reusable types or types defined outside of any interface, which is what you may be asking for. This is a feature we are interested in providing. We're not quite ready to share a design proposal on this, so I will leave this issue open until we get a proposal together to share.

sourabhkrishna commented 8 months ago

Any update on this?

jrdouceur commented 8 months ago

Wow, this is an old thread! I'm sorry to report that DTDL v3, which was released earlier this year, does not include this feature. It is a fairly straightforward addition to the language, but it requires extensive service changes to support storing, indexing, and retrieving definitions that are not Interfaces, which breaks a lot of assumptions throughout service code. This is recognized as an important use case, but it unfortunately did not make the cut relative to other service features that were in demand.