From de77b9142cc8e9db0632937f6f07c1efee7d7df1 Mon Sep 17 00:00:00 2001 From: Simon Heimler Date: Sun, 22 Dec 2024 06:43:45 +0100 Subject: [PATCH] Documentation Updates --- CHANGELOG.md | 4 ++++ docs/details/articles/data-product.md | 12 ++++++------ docs/index.md | 4 ++-- .../policy-levels/sap-core-v1.md | 1 - docs/spec-v1/interfaces/document.md | 4 ++-- static/spec-v1/interfaces/Configuration.xlsx | Bin 11012 -> 10960 bytes .../interfaces/Document.annotated.schema.json | 4 ++-- .../spec-v1/interfaces/Document.schema.json | 4 ++-- static/spec-v1/interfaces/Document.xlsx | Bin 22589 -> 22537 bytes 9 files changed, 18 insertions(+), 15 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 705afe8..6b63ee8 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -12,6 +12,10 @@ For a roadmap including expected timeline, please refer to [ROADMAP.md](./ROADMA - Allow apostrophe for plural proper nouns in Short Descriptions in Policy Level `sap:core:v1`, e.g. `partners'`. +### Changed + +- Removed constraint that `describedSystemInstance` MUST be same as system instance providing the ORD information + ## [1.9.8] ### Added diff --git a/docs/details/articles/data-product.md b/docs/details/articles/data-product.md index a15a8c3..a7479ad 100644 --- a/docs/details/articles/data-product.md +++ b/docs/details/articles/data-product.md @@ -4,9 +4,9 @@ description: A Data Product is a data set exposed for consumption outside the bo title: Data Product --- -# Data Product BETA +# Data Product -> 🚧 Please note that the [Data Products](../../spec-v1/interfaces/document#data-product) concept is currently in [Beta Status](#beta-status). +> 🚧 Please note that the [Data Products](../../spec-v1/interfaces/document#data-product) concept still has some missing and some beta properties. ## Definition @@ -35,7 +35,7 @@ The following aspects of the definition are essential: (1) [data](#data-aspect), * Above we say that Data Products are consumed via APIs, but to be precise, they are consumed via APIs or Events (we treat events as a special form of API). In this doc, we generally use the term APIs to include Events (it is just more readable than always saying "APIs and/or Events"). * There is a clear expectation that the APIs are described via [metadata](#metadata-aspect) for machine- and human-readable documentation. -* For Data Products only certain types of API Protocols and qualities (performant mass read) are adequate. +* For Data Products only certain types of API Protocols and qualities (performant mass read) are adequate. E.g. SAP uses [Delta Sharing](https://github.com/delta-io/delta-sharing/blob/main/PROTOCOL.md), which we additionally describe with [CSN Interop](https://sap.github.io/csn-interop-specification/) for richer metadata. * Data Products are also expected to describe their data lineage. This is done via Data Product input ports, which are described in details as an ORD [Integration Dependency](../../spec-v1/interfaces/document#integration-dependency) ### Metadata Aspect @@ -76,13 +76,13 @@ Data Products are exposed by **Producers** so that they can be used by **Consume * Data Product Consumers are applications or services that access and use the data from Data Products. Consumers can be of various types and cover both transactional and analytical applications. An application that processes operational data can be as Data Product consumer, as can analytical products like SAP Datasphere and SAP Analytics Cloud (SAC). * The Data Product Directory ([ORD Aggregator](../../spec-v1/#ord-aggregator)) is used by Consumers to find and discover available Data Products. -## Beta Status +## Current Status -Please note that the Data Product concept is currently in BETA. +Please note that the Data Product concept still contains some BETA properties. This has the following implications -* The interface contract is potentially subject to changes, although we aim to avoid breaking changes if possible. +* The beta-level properties are potentially subject to changes, although we aim to avoid breaking changes if possible. * Many data product relevant attributes are currently **not explicitly defined** in the specification yet. * Some attributes should be handled via documentation, e.g. Service Level Agreements via [dataProductLinks](../../spec-v1/interfaces/document#data-product_dataproductlinks) of `type`: [`service-level-agreement`](../../spec-v1/interfaces/document#data-product-link_type) * Such attributes need to be defined through generic extensibility mechanisms like `labels` and `documentationLabels` or added as text to the documentation. diff --git a/docs/index.md b/docs/index.md index 6e8f2a6..0f0d336 100644 --- a/docs/index.md +++ b/docs/index.md @@ -12,8 +12,8 @@ sidebar_position: 0
Open Resource Discovery (ORD) is a protocol that **allows applications and services to self-describe their resources and capabilities** (e.g. ports and adapters). -Typically, ORD is used to describe [APIs](./spec-v1/interfaces/document#api-resource) and [Events](./spec-v1/interfaces/document#event-resource), but it also supports higher-level concepts like [Entity Types](./spec-v1/interfaces/document#entity-type) (Domain / Business Objects) and [Data Products](./details/articles/data-product.md). -With [Integration Dependencies](./spec-v1/interfaces/document#integration-dependency) the use of external resources can be stated, too. +ORD can describe [APIs](./spec-v1/interfaces/document#api-resource), [Events](./spec-v1/interfaces/document#event-resource) and higher-level concepts like [Entity Types](./spec-v1/interfaces/document#entity-type) (Domain / Business Objects) and [Data Products](./details/articles/data-product.md). +With [Integration Dependencies](./spec-v1/interfaces/document#integration-dependency) the use of external resources can be stated. In case that the standardized concepts or attributes are not sufficient, there are extensibility attributes and [Capabilities](./spec-v1/interfaces/document#capability). All of the described artifacts can share relationships, taxonomy and [grouping](./details/articles/grouping-and-bundling.md) concepts, enabling a **well connected metadata graph**. diff --git a/docs/spec-extensions/policy-levels/sap-core-v1.md b/docs/spec-extensions/policy-levels/sap-core-v1.md index 303117b..8f8e5ae 100644 --- a/docs/spec-extensions/policy-levels/sap-core-v1.md +++ b/docs/spec-extensions/policy-levels/sap-core-v1.md @@ -141,7 +141,6 @@ The following constraints apply in addition to the constraints defined in the [O - Packages MUST NOT be shared by multiple provider (source) systems - Packages MUST NOT contain mixed resource types. E.g., a Package must only contain either APIs or Events, but never both together. - Packages MUST NOT contain content of mixed `visibility` - - SAP Business Accelerator Hub publishing becomes slow if too much content is in a Package (> 100 resources). Consider creating smaller packages that are split around the aspect of what needs to be published in one transaction. - The vendor of a Package MUST be set and be equal to one of the allowed values: `sap:vendor:SAP:`, `customer:vendor:Customer:`. ### Consumption Bundle diff --git a/docs/spec-v1/interfaces/document.md b/docs/spec-v1/interfaces/document.md index 133277f..392901f 100644 --- a/docs/spec-v1/interfaces/document.md +++ b/docs/spec-v1/interfaces/document.md @@ -28,7 +28,7 @@ The constraints and considerations on [ORD Documents](../index.md#ord-document) |
$schema
OPTIONAL
|
string
|
Optional [URL](https://tools.ietf.org/html/rfc3986) to the Open Resource Discovery document schema (defined as a JSON Schema).
If provided, this enables code intelligence and validation in supported editors (like VSCode) and tools.
JSON Schema Format: `uri-reference`
Recommended Values:
  • `"https://sap.github.io/open-resource-discovery/spec-v1/interfaces/Document.schema.json"`
| |
openResourceDiscovery
MANDATORY
|
string
|
Version of the Open Resource Discovery specification that is used to describe this document.
Allowed Values:

  • `"1.0"`: ORD Version 1.0

  • `"1.1"`: ORD Version 1.1

  • `"1.2"`: ORD Version 1.2

  • `"1.3"`: ORD Version 1.3

  • `"1.4"`: ORD Version 1.4

  • `"1.5"`: ORD Version 1.5

  • `"1.6"`: ORD Version 1.6

  • `"1.7"`: ORD Version 1.7

  • `"1.8"`: ORD Version 1.8

  • `"1.9"`: ORD Version 1.9


Example Values:
  • `"1.9"`
| |
description
OPTIONAL
|
string
|
Optional description of the ORD document itself.
Please note that this information is NOT further processed or considered by an ORD aggregator.

Notated in [CommonMark](https://spec.commonmark.org/) (Markdown).
Minimum Length: `1`
Example Values:
  • `"This ORD document contains all APIs that are system instance aware and have APIs that\ncan change their behavior at runtime.\n"`
| -|
describedSystemInstance
OPTIONAL
|
[System Instance](#system-instance)
|
Information on the **system instance** that this ORD document describes.

This information is optional, but RECOMMENDED to add, as it makes the ORD document self contained.
The described system instance MUST be identical to the system instance that provides the ORD information.
| +|
describedSystemInstance
OPTIONAL
|
[System Instance](#system-instance)
|
Information on the **system instance** that this ORD document describes.

This information is optional, but RECOMMENDED to add, as it makes the ORD document self contained.
| |
policyLevel
RECOMMENDED
|
string
|
The [policy level](../../spec-extensions/access-strategies/) (aka. compliance level) that the described resources need to be compliant with.
Depending on the chosen policy level, additional expectations and validations rules will be applied.

The policy level can be defined on ORD Document level, but also be overwritten on an individual package or resource level.

Default Value: `"none"`
Allowed Values:

  • `"none"`: No policy level chosen. Only the base rules on how to create correct ORD documents apply.

  • `"sap:base:v1"`: Basic SAP rules and guidelines apply. This just ensures technical correctness and essential validations.
    If chosen the [SAP Base V1](../../spec-extensions/policy-levels/sap-base-v1) rules MUST be followed.

  • `"sap:core:v1"`: SAP core rules and guidelines apply.
    If chosen the [SAP Core V1](../../spec-extensions/policy-levels/sap-core-v1) rules MUST be followed.

  • `"custom"`: Custom policy level.
    Further validation MAY be defined and implemented by the policy-level owner.
    This level MAY be chosen by 3rd party or customer solutions.
    If chosen, `customPolicyLevel` MUST be provided.


Introduced in Version: 1.3.0
Example Values:
  • `"sap:core:v1"`
| |
customPolicyLevel
OPTIONAL
|
string
|
If the fixed `policyLevel` values need to be extended, an arbitrary `customPolicyLevel` can be provided.
The policy level is inherited from packages to resources they contain, but can be overwritten at resource level.

MUST only be provided if `policyLevel` is set to `custom`.
MUST be a valid [Specification ID](../index.md#specification-id).
Regex Pattern: ^(\[a-z0-9\]+(?:\[.\]\[a-z0-9\]+)\*):(\[a-zA-Z0-9.\_\\-\]+):(v0\|v\[1-9\]\[0-9\]\*)$
Maximum Length: `255`
Example Values:
  • `"sap.xref:customPolicy:v1"`
| |
apiResources
OPTIONAL
|
Array<[API Resource](#api-resource)>
|
Array of all API Resources that are described in this ORD document.
| @@ -561,7 +561,7 @@ For example, OpenAPI definition, OData Metadata, etc. | Property | Type | Description | | -------- | ---- | ----------- | -|
type
MANDATORY
|
string
|
Type of the API Resource Definition
If "custom" is chosen, a customType MUST be provided
Allowed Values:

  • `"openapi-v2"`: [OpenAPI 2 / Swagger 2](https://swagger.io/specification/v2/) API Definition for [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) APIs.
    The `mediaType` MUST be be set to either `application/json` or `text/yaml`.

  • `"openapi-v3"`: [OpenAPI 3](https://swagger.io/specification/) API Definition for [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) APIs.
    The `mediaType` MUST be be set to either `application/json` or `text/yaml`.

  • `"raml-v1"`: [RAML](https://raml.org/) API Definition for [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) APIs.
    The `mediaType` MUST be be set to `text/yaml`.

  • `"edmx"`: [OData](https://www.odata.org/documentation/) APIs can be described via edmx XML files.
    For OData V2 APIs, this is standardized through the [Common Schema Definition Language (CSDL) V2](https://www.odata.org/documentation/odata-version-2-0/overview/#ServiceMetadataDocument).
    For OData V4 APIs, this is standardized through the [CSDL XML Representation](https://docs.oasis-open.org/odata/odata-csdl-xml/v4.01/odata-csdl-xml-v4.01.html)
    The `mediaType` MUST be be set to `application/xml`.
    The `apiProtocol` MUST be set to `odata-v2` or `odata-v4`.

  • `"csdl-json"`: [OData](https://www.odata.org/documentation/) V4 APIs can also be described via the
    [OData Common Schema Definition Language (CSDL) JSON Representation](https://docs.oasis-open.org/odata/odata-csdl-json/v4.01/odata-csdl-json-v4.01.html).
    The `mediaType` MUST be be set to `application/json`.
    The `apiProtocol` MUST be set to `odata-v2` or `odata-v4`.

  • `"graphql-sdl"`: [GraphQL](https://graphql.org/) APIs can be described via the [GraphQL Schema Definition Language](https://graphql.org/learn/schema/).
    See also: [GraphQL Specification > Type System](https://spec.graphql.org/October2021/#sec-Type-System).
    The `mediaType` MUST be be set to `text/plain`.
    The `apiProtocol` MUST be set to `graphql`.

  • `"wsdl-v1"`: [WSDL 1](https://www.w3.org/TR/wsdl.html) API Definition for [SOAP](https://en.wikipedia.org/wiki/SOAP) APIs.
    The `mediaType` MUST be be set to `application/xml`.
    The `apiProtocol` MUST be set to `soap-inbound` or `soap-outbound`.

  • `"wsdl-v2"`: [WSDL 2](https://www.w3.org/TR/2007/REC-wsdl20-20070626/) API Definition for [SOAP](https://en.wikipedia.org/wiki/SOAP) APIs.
    The `mediaType` MUST be be set to `application/xml`.
    The `apiProtocol` MUST be set to `soap-inbound` or `soap-outbound`.

  • `"sap-rfc-metadata-v1"`: Proprietary metadata description format for [SAP RFC](https://help.sap.com/viewer/753088fc00704d0a80e7fbd6803c8adb/202009.000/en-US/4888068ad9134076e10000000a42189d.html).
    The `mediaType` MUST be be set to `application/xml`.

  • `"sap-sql-api-definition-v1"`: Metadata description format for SAP SQL API, following the [SQL interface specification for SAP ecosystem](https://github.com/SAP/sql-interface-specification).
    The `mediaType` MUST be be set to `application/json`.
    The `apiProtocol` MUST be set to `sap-sql-api-v1`.

  • `"sap-csn-interop-effective-v1"`: CSN Interop Effective is a standardized and interoperable flavor of [CSN](https://cap.cloud.sap/docs/cds/csn)and a notation for compact representations of [CDS](https://cap.cloud.sap/docs/cds/) models.
    The `mediaType` MUST be be set to `application/json`.

  • `"custom"`: If chosen, `customType` MUST be provided.


Example Values:
  • `"openapi-v3"`
| +|
type
MANDATORY
|
string
|
Type of the API Resource Definition
If "custom" is chosen, a customType MUST be provided
Allowed Values:

  • `"openapi-v2"`: [OpenAPI 2 / Swagger 2](https://swagger.io/specification/v2/) API Definition for [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) APIs.
    The `mediaType` MUST be be set to either `application/json` or `text/yaml`.

  • `"openapi-v3"`: [OpenAPI 3](https://swagger.io/specification/) API Definition for [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) APIs.
    The `mediaType` MUST be be set to either `application/json` or `text/yaml`.

  • `"raml-v1"`: [RAML](https://raml.org/) API Definition for [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) APIs.
    The `mediaType` MUST be be set to `text/yaml`.

  • `"edmx"`: [OData](https://www.odata.org/documentation/) APIs can be described via edmx XML files.
    For OData V2 APIs, this is standardized through the [Common Schema Definition Language (CSDL) V2](https://www.odata.org/documentation/odata-version-2-0/overview/#ServiceMetadataDocument).
    For OData V4 APIs, this is standardized through the [CSDL XML Representation](https://docs.oasis-open.org/odata/odata-csdl-xml/v4.01/odata-csdl-xml-v4.01.html)
    The `mediaType` MUST be be set to `application/xml`.
    The `apiProtocol` MUST be set to `odata-v2` or `odata-v4`.

  • `"csdl-json"`: [OData](https://www.odata.org/documentation/) V4 APIs can also be described via the
    [OData Common Schema Definition Language (CSDL) JSON Representation](https://docs.oasis-open.org/odata/odata-csdl-json/v4.01/odata-csdl-json-v4.01.html).
    The `mediaType` MUST be be set to `application/json`.
    The `apiProtocol` MUST be set to `odata-v2` or `odata-v4`.

  • `"graphql-sdl"`: [GraphQL](https://graphql.org/) APIs can be described via the [GraphQL Schema Definition Language](https://graphql.org/learn/schema/).
    See also: [GraphQL Specification > Type System](https://spec.graphql.org/October2021/#sec-Type-System).
    The `mediaType` MUST be be set to `text/plain`.
    The `apiProtocol` MUST be set to `graphql`.

  • `"wsdl-v1"`: [WSDL 1](https://www.w3.org/TR/wsdl.html) API Definition for [SOAP](https://en.wikipedia.org/wiki/SOAP) APIs.
    The `mediaType` MUST be be set to `application/xml`.
    The `apiProtocol` MUST be set to `soap-inbound` or `soap-outbound`.

  • `"wsdl-v2"`: [WSDL 2](https://www.w3.org/TR/2007/REC-wsdl20-20070626/) API Definition for [SOAP](https://en.wikipedia.org/wiki/SOAP) APIs.
    The `mediaType` MUST be be set to `application/xml`.
    The `apiProtocol` MUST be set to `soap-inbound` or `soap-outbound`.

  • `"sap-rfc-metadata-v1"`: Proprietary metadata description format for [SAP RFC](https://help.sap.com/viewer/753088fc00704d0a80e7fbd6803c8adb/202009.000/en-US/4888068ad9134076e10000000a42189d.html).
    The `mediaType` MUST be be set to `application/xml`.

  • `"sap-sql-api-definition-v1"`: Metadata description format for SAP SQL API, following the [SQL interface specification for SAP ecosystem](https://github.com/SAP/sql-interface-specification).
    The `mediaType` MUST be be set to `application/json`.
    The `apiProtocol` MUST be set to `sap-sql-api-v1`.

  • `"sap-csn-interop-effective-v1"`: [CSN Interop Effective](https://sap.github.io/csn-interop-specification/) is a standardized and interoperable [CSN](https://cap.cloud.sap/docs/cds/csn) export, used to describe [CDS](https://cap.cloud.sap/docs/cds/) models.
    The `mediaType` MUST be be set to `application/json`.

  • `"custom"`: If chosen, `customType` MUST be provided.


Example Values:
  • `"openapi-v3"`
| |
customType
OPTIONAL
|
string
|
If the fixed `type` enum values need to be extended, an arbitrary `customType` can be provided.

MUST be a valid [Specification ID](../index.md#specification-id).

MUST only be provided if `type` is set to `custom`.
Regex Pattern: ^(\[a-z0-9\]+(?:\[.\]\[a-z0-9\]+)\*):(\[a-zA-Z0-9.\_\\-\]+):v(\[0-9\]+)$
Maximum Length: `255`
Example Values:
  • `"sap:custom-definition-format:v1"`
| |
mediaType
MANDATORY
|
string
|
The [Media Type](https://www.iana.org/assignments/media-types/media-types.xhtml) of the definition serialization format.
A consuming application can use this information to know which file format parser it needs to use.
For example, for OpenAPI 3, it's valid to express the same definition in both YAML and JSON.

If no Media Type is registered for the referenced file,
`text/plain` MAY be used for arbitrary plain-text and `application/octet-stream` for arbitrary binary data.

Allowed Values:

  • `"application/json"`

  • `"application/xml"`

  • `"text/yaml"`

  • `"text/plain"`: For a plain-text format where no other serialization Media Type fits

  • `"application/octet-stream"`: For a binary format where no other serialization Media Type fits


Example Values:
  • `"application/json"`
| |
url
MANDATORY
|
string
|
[URL reference](https://tools.ietf.org/html/rfc3986#section-4.1) (URL or relative reference) to the resource definition file.

It is RECOMMENDED to provide a relative URL (to base URL).
JSON Schema Format: `uri-reference`
Example Values:
  • `"/api/openApi.yaml"`
  • `"https://example.com/api/API_RFQ_PROCESS_SRV/$metadata"`
| diff --git a/static/spec-v1/interfaces/Configuration.xlsx b/static/spec-v1/interfaces/Configuration.xlsx index b2aa055123a75848073fb6bf949e35fb10747861..c2b47d043a4dfbb005105ef77b9ab2d4f748e9a4 100644 GIT binary patch delta 937 zcmY+D?MqW(7{<@ej+><&W!c(F<~HV@Z8?a|w>8t%il+ABqK!&Yk{q>gtXzeI8bp79 za;VQ5F(`In_8aY*cnj zl2k8cgNy2dEN6pSMfMQ-g}w4ies7@qjp8C~DFUb{bw6}>$J9Zs)4ZS%R~w4@`*Br& zDyI%Mkp0eHreST;q1&^LEx9op++JC}gfz9?&}LlT(pl7pn<0pOgy$O6*}{$jh=40e z%pj+3LN=d3+L0W6wMyioQEu+{j<%w5BMr#(wB?-J!b6u6Ox6+*LJDLYsT_hJA`Ixs z2asFH+f(dijn?Yo2mNG+Mf3!Co=4Ro&^rd9eXYN}#&&fS4b9?B7ETSvytdGGX=T|4 zBa`>=b2W`@KJB87 zH>y+6i*graqJET)d;n>#n}*gR(cDDm=YBi@-s4)LLq-Q7d)W9_i{yKTGFRE84v}MY zo&nd&+^oL_|8D%_JloK5Bwqj%-++q6qhEnJwN?A-4bs0>5#5A-5hFYlVZxG#5Ppjh z!j7p$8}s?7begT&ye~xMcVB|ABph1IZ>KV++O#`T1{svQY*{C_L% K2J|&5f#e_ep!mrE delta 983 zcmZXTUr1AN6vx+gb90k9W=>pdG8?GkI+6zo@PPo_G#x%mjWiy0nIB@8xTw(T@?d*eKy7pg71UqYgjAv{@FOCF{`MR!ci z4+73dN8xs#GSMi>^+3-BSkKrnoKA`;)XR=SqKle{HfW5F-uyv3GEGzb(9v!fwP+B7 zCLj~-7Jv}rlXEAK6g%wPc1fl3ZVOC;GEhIw7(Qw3Kq7rxfFZITchqtN&;p(18vHUn z2qL}LC;=|<;LAPlV2+WtpoedwQyVd&?g8)5(Mu@M>D|TZ;~CnaT844ZVq3TG?~Kt; zkEupI4Jy)QMxf@86`4D`jw4Ue<9)srua?%{^a1H!W+4Q<+UynP>uQ~T_p}(TzxwVB zx8x{icKzbVDGxyT-cuo@jknx3oZdXg`cnfh(mnk9XFx$I!Ya04iNE9r4L)rp)IlFg zQrimkFoeVe!=!kKp)4L|*c3Aik#L;BW%X$D;e$MQ9ZoTnMZe~iT6xedB^ho?eGJQz W%wWf{S#@y63h)vBgqtcomD|4}PP9-*!8nsYXE+V0J8G$$U zQa9c7g;0=A7IiheiU@+6*G%_pp z!t>ykY447?2;EV59T_@6T8b{{_eP7c^5}DHOR7x=c2|m*0Yl48u{h$*jldtP2cZs< zycJ-ll@mS0*Wrqjrhutipv`BXR)DLw>U`6Y2saOU#vE{NKno}{4Hw)EJi0Q-%AA7) z0Uyv0==~s6m<4?HA?P-6XNt45&Q^K(;dY8czQ`HqMV?xQq28+?TG!ggYaCamXy_^4 zcy=Im%4-kq=2nV!1gVUNud8x+^HmppmOgE3Teg$qEQGd%8V}q6hpy8Kx-;^u+sHZi z^d))Y4R`d`+_{s=>QZ%@`2Ma3O>ZMD&t}i1s}q*o8>KGLq-l({+zc3NX28`NtgoZ}bD!*h-ea$!O-6=5W)A-4 zS;{@bsR<6LLrt@Eo`$g_^q__FibM8_Wgf4meg{-qsIRLSnvha delta 1018 zcmZWo?MqW}6yBR|Zkl78bLE;$L$IZ5W^TEO%UY=`+ibgQESl1iN(|hhMo_EuDaayj z1Qvo31VNB-5h4^J6GlXR$?!`A_1y~k1A2~UU5Vg4&w0+v@9qBX@7A1haZb4<5>{*U z3WY+a__4GYdRhHgr6D1{Q0-umifxtFRSQavo@<;eJc331t}$~^6Sqs2iudK7ZuYEA$)diKg;xTGGG+DH{B-Jk}w0ui8(I-*CkZE%Dy zMG$P*YI3PBL(~Ha&VkR+L0|*Tath)!2cK_m8;rB0CFt;G+O=##VLNntoIXO9c5lj+ z9$ussN;4ofnr!{X-3lKK-CvON15i1-%$-2p2g%D7%K`XtI^L)2fztHyd@m&3OCEsH zryV}W`ck2?eD^dN&HrZM7?->*_RQsrA0>Yf$aEiVf&2KH%QDlKXIq(-Wt#5c-$#N( zG6#}+qSO3Z?p52x-^bhNM+u3|u`U*=Sdhg`Y!3^M;1GYt8aSwlM_8oe0TxEBO`MN+ wa4^|n6O}?c2Oh!8V#;q5i-Ma2N$CAsc8I1#d0uy-@Bim=HL;IdUnQb{0Ay}HWB>pF