Create Typed Data "Logger Entry" type

Reading in on d8 TypedData: https://api.drupal.org/api/drupal/core!lib!Drupal!Core!TypedData!Plugin!...

The "map" data type represent a simple complex data type, e.g. for representing associative arrays. It can also serve as base class for any complex data type.

The current array

$logger_entry = array(
      'uid' => $context['uid'],
      'type' => $context['channel'],
      'message' => $message,
      'variables' => $message_placeholders,
      'severity' => $level,
      'link' => $context['link'],
      'location' => $context['request_uri'],
      'referer' => $context['referer'],
      'hostname' => $context['ip'],
      'timestamp' => $context['timestamp'],
    );

Moving to
https://github.com/fago/rules/pull/315

I am still in a doubt.

There are 3 ways I've been investigation and I cannot make a decision about how logger_entry should be handled:

• Extend \Drupal\Core\TypedData\Plugin\DataType\Map
• Use config/schema/rules.schema.yml
• Make it an entity with all the bells and whistles

Notes:

approach new DataType

Extend \Drupal\Core\TypedData\Plugin\DataType\Map
Doing class LoggerEntry extends Map with annotation definition_class = "\Drupal\rules\TypedData\LoggerEntryDataDefinition" initiating new LoggerEntry() gives a runtime-error that the definition must be passed to the LoggerEntry __constructor.
This is probably just wrongly implemented by me.
Have been looking through a lot of core-examples of extends Map() and other TypedDate implementations. But I could not find one or more with this typical 'associative array with a couple of fixed keys and expected values' setup like logger_entry has.

Via .yml

config/schema/rules.schema.yml
This method seems to be used for config-entities only. The definition (via .yml) looks very clear and simple though.
see below for the .yml I made up for now.

Make it an entity

Make it an entity with all the bells and whistles
Seems a fine approach, all though I could imagine it might have performance impact.
I am not sure if this means that all logger_entries now should be saved to the db or not.
But it could be an attractive approach because of a lot of integrations we get for free.

Example *.schema.yml for logger entry

rules.data_type.logger_entry.definition:
  type: mapping
  label: 'Logger Entry'
  mapping:
    uid:
      type: user
      label: 'User'
    channel:
      type: string
      label: 'Channel'
    message:
      type: string
      label: 'Message'
    variables:
      type: string
      label: 'Message placeholders'
    severity:
      type: string
      label: 'Level'
    link:
      type: link
      label: 'Link'
    location:
      type: url
      label: 'Request URI'
    referer:
      type: string
      label: 'Referer'
    hostname:
      type: string
      label: 'IP'
    timestamp:
      type: data
      label: 'Timestamp'

@TR nope, I unassigned myself