id field should be renamed or have its keys moved to the body of the object

[ruhnowg]

Currently all of the objects that have ids are represented something like this:

{
  id: {
    [key: string]: string
  }
}

This may represent a challenge when trying to integrate these objects into existing infrastructure as id is a very common field and almost always represents a string value. From the perspective of this effort the field that the ids live under has no impact on the spec itself, but there likely would be a cost to consumers of the spec attempting to integrate it into existing workflows as id is an incredibly common field and likely already exists in those workflows as something else.

I propose that either:

1. id is renamed to another field, maybe 'ids'
   • This would be more semantically correct as it implies multiple ids rather than a single id
2. the keys and values from id could be moved onto the base object
   • I frequently work with financial objects as a part of my role at FactSet and have generally found that nesting identifiers under another value only serves to make the object more difficult to work with. The spec already specifies what ids should be specified by a given type, so there should be no confusion about which fields are identifiers.

[RichLinnell]

Personally I favour option 2. I don't think putting the Ids into a separate object gives us anything.

[rikoe]

@ruhnowg @RichLinnell as discussed in the Context Data & Intents working group, this would be a major breaking change to the schema in FDC3 1.0, which is in use today.

Are you okay with us closing this issue and continuing to use the context data interface as it is today?

[rikoe]

Closing due to inactivity