Project and unit field integrations

jensstalder commented 3 years ago

Semantic versioning

This PR is a Minor (It was aggreed that the change will not affect 3rd party folks since it has not been used yet)

Generall things to consider

I have read the CONTRIBUTING.md document.
If my change requires documentation, I added it already.
I have added tests to cover all my changes.
All new and existing tests pass.

List of issues related to this PR

closes #162
closes #142

Notable changes

Added

Fields to project and units

Changed

Direction of relationships between property and units

boeschenstein commented 3 years ago

Although it is not written in the docs yet (and this might be our own understanding), in general, ID fields are technical fields (from the source system), and "Reference Id" are logical fields. Therefore, I suggest renaming the new field from "projectUnitId" to "projectUnitReferenceId", so is clear that the link goes by project-unit-referenceId (not project-unit-id).

Please add information about the Id fields to the docs, so the usage is getting clearer.

jensstalder commented 3 years ago

My hope was to use the attribute id= so that we could make use of validation. similar to how html uses id attributes together with anchors for example. But I could not make this work. This would however require for the reference entities to be present in the XML document to make it valid. There are pros and cons to that. What do you think?

When I google this topic it's a bit weird.

Maybe you can find something more legible?

This is what is currently documented:

id
          this ID needs to be unique and represents the id from the exporter (this can be the same as referenceId if the exporter is the original creator)  

referenceId
          Can be used to track the original creation id (this should usually be unique to the property) 

visualReferenceId
          Can should only be used for presentational purposes publishers tend to present the referenceId if this one is missing

It does have implicit meaning that the "id" or more of a technical/structural id but that a consumer/importer should look at referenceId for import duplication checking instead. But internal referencing would actually use the id attribute if we want to go the "xml way" route.

jensstalder commented 3 years ago

Ok I got it working with the unit reference. The only thing that was missing. I also added examples and a test for this. See examples/project-tree.xml.

The only change is that I renamed the reference element to simply <unitId> and it now checks that it is valid.

I checked and it would also be possible to connect to <unit><referenceId> instead, but this is up for debate still? What do you guys think. Should we reference id="" or <referenceId>?

jensstalder commented 3 years ago

<xs:element name="availability" minOccurs="1" maxOccurs="1"> For projects are "extending" the availability from properties. Which in my opinion does not make sense, since a project can't be "reserved" or "in-acquisition" or "taken". So we should change that enum to just have "active" for the moment. And we can add more in the future such as "private" if they make sense for projects.

qualipool / swissrets