TBD: Explicit Deletion of Properties

cwill-evonier commented 3 years ago

Problem description

Currently a realtor has to provides all his properties within one single XML-file. The distinction whether a property should be deleted happens implicitly: If the realtor, in comparison to his previous import, leaves out one or more properties, those properties must be deleted automatically.

This implies that each provider has to check the delta and remove previously imported listings.

Desired Solution

This issue won't provide any solution to this topic, the purpose is to open a discussion between stakeholders, if this workflow is the desired one or if the SwissRets standard could benefit from some sort of CRUD-attributes.

Just to clarify this issues by a simple example:

<?xml version="1.0" standalone="yes"?>
<xs:schema>
  <xs:simpleType name="propertyStatus">
    <xs:annotation>
      <xs:documentation>Status that indicates the desired status of a property.</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="CREATE-UPDATE" />
      <xs:enumeration value="DELETE" />
    </xs:restriction>
  </xs:simpleType>
  [...]
</xs:schema>

jensstalder commented 3 years ago

Hi I will summarise my point of view discussed within the slack channel.

For me a XML feed represents the state of something, and sync-instructions within it seam out of place.

You can compare that to a REST situation with json as a body. There it would also be weird to have instructions in the body, and that is why one uses the get parameters or header section of the request (in this example http).

I agree that it is important to collaborate about this, but the schema itself might be the wrong place to try and solve this.

jensstalder commented 3 years ago

What we could elaborate on within the xml standard. Would be to have a single property xml as a root, so that people could implement direct CRUD implementations themselves using this root element.

cwill-evonier commented 3 years ago

Agree on not adding CRUD-actions to the schema itself: transportation != schema.

However, to bring a more generic perspective into consideration we should challenge the send-all-at-once approach:

Simplify complexity: Multiple properties per file lead to multi-status responses
Multiple status must be processed and understood by the consumer (feedback channel).
Implicite deletions are problematic and fraught with risk
Delta-lookups (for deletions) are not performant

qualipool / swissrets

TBD: Explicit Deletion of Properties #174