Support of annotation on type reference

[r0b0ji]

An ISL schema is Ion and Ion supports any custom annotation on type fields. ISL could also support, but it is explicitly been not allowed as per this code [1]. Not sure why when this could have been easy to be allowed.

My use case: I want to create a custom type, which wrap Type and adds some custom logic for equals, which was based on the annotation on the type field.

Ex:

Class MyType {
  final com.amazon.ionschema.Type type;
  final Set<String> comparatorIgnoredFields;
}

And then want to define the schema like

type::{
  name:'my_custom_type',
  type:struct,
  fields:{
    a:{
      type: string,
    },
    b:'comparator.ignore'::{
      type:string
    }
  }
}

In this, case the type will have field a and b but I write my equals method to ignore b while comparing. This is very toned down example but basically I want to be able to add annotations on type fields and it should be retained, so that when I call type.getIsl() I should have this annotation intact so that I can do custom logic based on the annotations.

But, as of now this fails at the line mentioned in TypeReference.kt

[1]

ion-schema-kotlin/ion-schema/src/main/kotlin/com/amazon/ionschema/internal/TypeReference.kt

Line 58 in bbab678

IonSchemaVersion.v2_0 -> validateIonSchema2TypeReference(ion, variablyOccurring, isNamePermitted, allowedAnnotations)

[popematt]

Thanks for reaching out!

Not sure why when this could have been easy to be allowed.

Ion Schema Kotlin does not allow adding arbitrary annotations because the Ion Schema specification does not allow unknown (or "open content") annotations, and the implementation needs to follow the specification. (See Open Content of the ISL 2.0 specification.)

I agree, though, that it is certainly possible to allow arbitrary annotations in ISL. When we were working on ISL 2.0, no one was asking for arbitrary annotations, so we didn't consider it. If this is a use case that you feel strongly about, you could create a feature request in amazon-ion/ion-schema to start a discussion about allowing open content annotations in the next ISL spec version.

For the short term, however, you may want to consider some of the following alternatives.

type::{
  name: my_custom_type,
  type: struct,
  fields: {
    a: string,
    b: string,
  },
  // Here is an allowed open content field that lists which fields should be ignored
  _comparator_ignore : [b]
}

type::{
  name: my_custom_type,
  type: struct,
  fields: {
    a: string,
    b: {
      // Here is an allowed open content field within the definition of field 'b'
      _comparator_ignore: true,
      type: string,
    }
  },
}

Since the comparator logic belongs to my_custom_class, my preference would be to use the first option, but you can do whichever seems best for you, or come up with something different.

[r0b0ji]

This can be closed, I opened a discussion issue in amazon.ion/ion-schema [1] amazon-ion/ion-schema#132