Produce interopCSN

[stewsk]

Hi @zongqichen , this PR adds the "interopCsn" marker and does a first annotation replacement. Can be extended on demand.

[stewsk]

unrelated to this PR, while testing I ran into two problems that propabaly are due to differences Mac/Windows: see #158

[swennemers]

@stewsk : we would need meta.document.version, I would propose to take it from the data source annotation.

[stewsk]

wouldn't that be the version of the data product itself rather than the data source?

[Fannon]

yes, it needs to go into meta.document.version, or if we have a CDS Service, the version number could be added as annotation there (is there some annotation in CAP to add a full version to a service?)

[stewsk]

if we have a CDS Service

In CAP, for a Data Product there always is a service

is there some annotation in CAP to add a full version to a service?

no

[swennemers]

true, it is more the version of the data product. We should probably have a sync on the detailed content for the meta section (incl. name + namespace)

[swennemers]

summary of the sync between @stewsk and @swennemers :

meta:{
    "__name": "<service name>", // clarify if it should be 
    "__namespace": "<service namespace>",//service namespace should be in line with namespace registry namespace as this is a newly build service for data products.
    "document": {
      "version": "1.0.0" //CAP service version / application version or start hard coded.
    }

for the dpd files, that cut this csn per entity, the name and version must reflect the data source name, namespace and version that is maintained on the entity level.

[Fannon]

Do we need to expose this at all on CAP level? You'll describe the service in ORD as well and then the ORD information and ORD ID would already contain the information.

[swennemers]

we must not have "kind" : "event" in the csn