Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: formalize datetime profile as a feature of OCSF schema definition #969

Open
4 tasks
alanisaac opened this issue Feb 20, 2024 · 2 comments
Open
4 tasks
Labels
framework Structures, conventions, requirements, data types, etc. non_breaking Non Breaking, backwards compatible changes

Comments

@alanisaac
Copy link
Contributor

alanisaac commented Feb 20, 2024

Background

Today, the datetime profile is a "special" profile:

  • The profile defines no attributes to overlay onto objects.
  • Instead, the schema server defines its behavior, where it adds a datetime attribute to any timestamp attributes on the object.

This means that:

  • The schema definitions defined in https://github.com/ocsf/ocsf-schema are not sufficient to fully define the object and class schemas for OCSF.
  • Any tool that is written for OCSF to go from schema definitions to schemas (in lieu of the schema server) would need to duplicate the behavior, without a formal definition for it.
  • For better or worse, it creates a type of profile that cannot be replicated in extensions.

This intent of this proposal is to formalize the mechanisms behind the datetime profile into a feature of profiles themselves. This would allow the datetime profile to be defined in the OCSF schema definition language.

Proposal

Add a new feature to profiles that allows them to define the behavior of the datetime profile. The behavior is:

  • For every attribute with timestamp_t on a schema, add a sibling datetime_t field with the suffix _dt.

As a feature of profiles, these three attributes could be codified under a new top-level property or $special_property.

The intent of this change would be to be non-breaking. That is, it should not modify any of the actual schemas, only the way this profile is defined.

Example

This is a simple example of how this information could be codified. The names of these properties in the schema definition language below are just examples; all four can be renamed based on feedback.

{
  "description": "This profile defines date/time attributes as defined in RFC-3339. For example 1985-04-12T23:20:50.52Z.",
  "meta": "profile",
  "caption": "Date/Time",
  "name": "datetime",
  "attributes": {
      "$append": [{
          "foreach_type": "timestamp_t",
          "append_type": "datetime_t",
          "suffix": "_dt",
      }]
  }
}

I chose to go the $special_property route because I thought defining it under attributes made sense, as it was manipulating attributes, similar to an attributes.$include.

Work

This section is intended to capture the work that would need to be done in order for this change to be enacted.

  • Add code to read the new attribute from schema definition files to the schema server
  • Update the metaschemas to allow and document this as a feature of profiles
  • Update the OCSF documentation to explain this as a feature (and integrate with the existing documentation for datetime)
  • Update the datetime profile itself
@dkolbly
Copy link
Contributor

dkolbly commented Feb 27, 2024

It might be helpful to collect some use cases where we might want to use this feature, so we can kind of understand the scope of what we might want to cover. The concept of enum strings came up in the call, for example, and something about observables as well.

@floydtree
Copy link
Contributor

I like the idea. We can expand this mechanism in general to "sibling" attributes across OCSF. The concept of sibling exists in the framework (currently used in string/int enum attributes - e.g. activity, activity_id), but it's not codified anywhere. This is probably a good opportunity codify.

@alanisaac alanisaac added framework Structures, conventions, requirements, data types, etc. non_breaking Non Breaking, backwards compatible changes labels Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
framework Structures, conventions, requirements, data types, etc. non_breaking Non Breaking, backwards compatible changes
Projects
None yet
Development

No branches or pull requests

3 participants