Documentation Updates

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

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 <span className="feature-status-beta">BETA</span>
+# 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 <span className="feature-status-beta" title="This feature is in BETA status and subject to potential changes.">BETA</span>.
+Please note that the Data Product concept still contains some <span className="feature-status-beta" title="This feature is in BETA status and subject to potential changes.">BETA</span> 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.

docs/index.md

@@ -12,8 +12,8 @@ sidebar_position: 0
 <div className="col">
 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**.
 

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