Vendor-specific schema elements?

[janczawadzki]

I've noticed some vendor-specific elements, specifically in icarReproHeatEventResource: heatReportScrSenseTime and heatReportNedapCowControl.

These seem like they could be abstracted out and made more generic, with the vendor code to indicate the source system.

Is the intent to gradually support other vendors?

[cookeac]

We're very keen to do that. At the time of creating version 1.0, the participants didn't have sufficient information to generalise those additional fields (though we did generalse what fields we could). We also needed to support existing messages used by some participants.
Going forward, our preference is that the ICAR specifications should only contain generalised fields, as implementations may add extra implentation-specific fields.

[erwinspeybroeck]

It seemed not easy to really generalise the Nedap vallues with the SCR values and vendors tend to offer something more. We didn't have specifications of what other vendors might be able to put in a response. So if you have information about other vendors, please inform us - and of course you can propose actions we could take to generalise this further.

[ghost]

I find the point valid. Specific suppliers can always add additional data to the message, if that is required. I'd prefer to leave vendor specific parts out, if possible. We could just say that we have a property "heatReportByDevice" and allow basically any object with any properties there. Each supplier could provide a specific implementation of that object until we can define a standard object.

[alamers]

So the proposal is to remove the vendor specific fields from the standard?

Actual implementations (like ours) will of course simply keep them in. I agree that we should aim for generalization, but there doesn't seem any progress on generalization here yet.

There is some value in exposing the fields as they are since this tells you how those vendors will operate. But it also may 'pollute' the standard a bit. Do we, in general, want to publish vendor specific fields if they are known? Or do we always leave them out, even if a vendor strongly commits to keeping it as part of (his/her) standard?

[alamers]

Note: #94 is the ticket for generalizing these messages.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ghost]

Maybe we could remove the fields for a version 2.0? The data could still be transmitted in the same fields and we could take care of a standardization in a new issue, if that is required.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.