0

我正在使用弹性搜索存储 XBRL JSON。

此 xBRL-JSON OIM 规范描述了该oim:period属性：

否则，表示 {interval} 属性的 ISO 8601 时间间隔，以下列形式之一表示：

<开始>/<结束>

<开始>/<持续时间>

<持续时间>/<结束>

其中 <start> 和 <end> 根据 xsd:dateTime 数据类型有效，<duration> 根据 xsd:duration 有效。

arelle 插件的示例如下所示：

  • 2016-01-01T00:00:00/PT0S
  • 2015-01-01T00:00:00/P1Y

我注意到 arelle 的插件专门产生这种格式：

  • <开始>/<持续时间>

我的问题

有没有办法在elasticsearch中至少将<start>部分保存为日期类型？

我的想法：

仅弹性搜索（我的偏好）

  • 使用预期部件的自定义日期格式/<duration>，但忽略它
    • 我还没有检查乔达；如果它们不是特殊字符的一部分，它会忽略日期格式的字符吗？像“/”分隔符或任何持续时间值之前的“P”（如PT0S及P1Y以上）？
    • 编辑所以单引号字符转义文字；这个作品yyyy'/P'将接受一个值'2015/P'。但是，其余的持续时间可能会更加动态
    • 回复：动态；Joda 会接受正则表达式或通配符，如“\d”或“+”限定符，因此我可以忽略P?
  • 在仅保存为日期时间之前，使用字符过滤器去除/<duration>部分。<start>但我不知道字符过滤器是否在保存为类型之前发生：日期。如果他们不这样做，'/` 部分不会被剥离，我也不会传递有效的日期字符串。
  • 不要使用日期类型：使用模式分词器在 上拆分/，并且至少将两部分保存为单独的分词。但是，不能使用日期数学。
  • 使用转换；尽管这似乎已被弃用。我阅读了有关 using的信息copy_to，但这似乎结合了术语，我想将这个术语分开
  • 某种插件？也许一个插件将完全支持 OIM 规范描述的这种“间隔”数据类型......也许一个插件将存储其单独的部分......？

更改我的应用程序（如果可能，我更喜欢使用仅弹性搜索技术）

  • 我可以编辑这个插件或制作我自己的插件，它专门使用<start>和<end>部分，并将两者保存到单独的字段中；
    • 但这违反了 OIM 规范，该规范说它们应该组合在一个字段中
    • 此外，表达“即时”事实可能很尴尬（没有持续时间；PT0S上面的例子）；我想我只是使用与end属性相同的属性值start......我猜这并不比 0 长度的持续时间 ( PT0S) 更尴尬。
4

1 回答 1

1

不是一个直接的答案，但值得注意的是，xBRL-JSON 规范的最新内部草案已经脱离了单字段表示。尽管“/”分隔符号是 ISO 标准，但对它的工具支持似乎极差，因此工作组选择切换到开始日期和结束日期的单独字段。我希望阿雷尔的支持会在适当的时候效仿。

于 2016-05-11T14:57:02.943 回答