dma61 / VBPUOdsk

3 stars 0 forks source link

Request for change: (Bericht 1) party, commonFunctional, and commonTechnical should not be arrays #9

Closed cnrd closed 9 months ago

cnrd commented 9 months ago

Hi

I am currently implementing the spec using the provided JSONSchemas, however when I compare the provided schema with chapter 7.6 of "Resultaten onderzoek: Standaard voor data-uitwisseling pensioenuitvoering & vermogensbeheer partijen", the JSON does not seem to match.

Screenshot 2024-01-19 at 16 10 31

The schema requires an array of exactly 1, while the example in the PDF just has the object structure directly defined. I think that it feels a bit weird to have an array of exactly size 1 and I think that the solution provided in the document is much better.

So my proposal is to replace the lines I have referenced below with this:

    "commonFunctional": { "$ref": "#/definitions/commonFunctional" },
    "commonTechnical": { "$ref": "#/definitions/commonTechnical" },
    "party": { "$ref": "#/definitions/partyPensionProvider" },

In this case we just define the object directly instead of having an array containing the object.

https://github.com/dma61/VBPUOdsk/blob/ba3d11cbbf127fea202f17a7864e438a7d5e892b/Bericht%201.%20Vermogen%20(0001a)-Vermogen_1/Bericht%201.%20Vermogen%20(0001a)-001.00-Vermogen_1.json#L481-L509

https://github.com/dma61/VBPUOdsk/blob/ba3d11cbbf127fea202f17a7864e438a7d5e892b/Bericht%201.%20Vermogen%20(0001a)-Vermogen_1/Bericht%201.%20Vermogen%20(0001a)-001.00-Vermogen_1.json#L536-L548

kooskaspers commented 9 months ago

I agree with your suggestion.

sreiz-azl commented 9 months ago

Beste @dma61, graag een reactie - het is voor Festina goed om duidelijkheid te hebben mbt de implementatie die ze doen.

dma61 commented 9 months ago

@sreiz-azl @cnrd

Binnen SIVI AFS zijn entiteiten altijd een array, ook als deze maar één object telt, of maar één soort entityType (zoals pensionProvider onder party). Vanuit consistentie-perspectief definiëren we daarom altijd de array, of er nou één entityType onderhangt of meerdere.

Within SIVI AFS, entities are always an array, even if it only contains one object or only one entityType (such as pensionProvider under party). From a consistency perspective, we always define an entity.entitytype as an array, whether there is one or multiple.

See also chapter 2.4 of the manual : https://www.manula.com/manuals/sivi/sivi-all-finance-standard/1/en/topic/data-types-and-formats " Another innovation is the addition of arrays. By reducing the number of entities in AFD 2.0, entities increasingly occur repeatedly in a message or function. With the newly introduced support from JSON, a syntax has been chosen that intrinsically supports arrays, as opposed to XML. Therefore, all entities in AFD 2.0 are arrays by default, even if only one instance is defined within the message. Building on this development, and also regarding eliminating redundancy in the data catalog, some attributes are also used as array. Example attributes are coverageAreaCode (_GEBIED) and companyTypeSpecification (_SBISPCC): a coverage can apply to multiple areas (codelist ADNDKG) and a company can have multiple company types from the corresponding codelist (ADNABS). In XML, arrays will be represented as an xs:list. "

cnrd commented 9 months ago

Thank you for clarifying! also thank you for the data type link, that is going to help with getting the data types right.