search

gs1 / EPCIS

Draft files being shared for EPCIS 2.0 development
Other
20 stars 7 forks source link

Include sensor alert type within sensor report in EPCIS 2.0 draft #247

Closed shalikasingh closed 3 years ago

shalikasingh commented 3 years ago

Hi @mgh128 , @CraigRe ,

We were curious to know if Alert Type within the sensor element is intentionally not mentioned in 2021_03_23b EPCIS 2-0 COMMREV or is it a miss.

In case it is a miss, we must include it.

CraigRe commented 3 years ago

Thanks for picking this up, @shalikasingh ; we are also missing Measurement Type. I'll fix these omissions.

mgh128 commented 3 years ago

Thanks @shalikasingh , @CraigRe

Please note that based on feedback received, the proposed code list is likely to be gs1:SensorAlertType rather than gs1:AlertType
So far we have defined two values within that code list:

gs1:SAT-ALARM_CONDITION gs1:SAT-ERROR_CONDITION

shalikasingh commented 3 years ago

Hi @CraigRe ,

You are welcome. BTW, I believe we are not missing Measurement Type. As "type" attribute within the sensor report represents Measurement Type.

Please rectify me here if needed.

mgh128 commented 3 years ago

Hi @shalikasingh , @CraigRe

You're correct that within SensorReport, the type attribute expects a Web URI / CURIE value from one of: https://gs1.org/voc/MeasurementType (for regular sensor reports) https://gs1.org/voc/SensorAlertType (for reporting alarm conditions or error conditions) user-defined / vendor-defined Web URI or CURIE when neither of the above is appropriate.

shalikasingh commented 3 years ago

Hi @mgh128 ,

I really think it will be helpful for implementors if we can find room to adjust your above statement in EPCIS 2.0 draft. As its a new discovery to me that "type" attribute can accept the three kinds of value mentioned by you.

mgh128 commented 3 years ago

Hi @shalikasingh

I'm tagging @CraigRe to consider making that adjustment. Throughout EPCIS we usually support user-defined / vendor-defined values in situations where the standard values (defined in CBV in v1.2, CBV+GS1 Web vocabulary in v2.0) are not sufficient. Since type is an inline attribute in the XML data binding, the only way we can support a user-defined / vendor-defined value is to allow it as a Web URI / CURIE alternative to a value selected from either https://gs1.org/voc/MeasurementType (for regular measurements) or from https://gs1.org/voc/SensorAlertType (for alarm/error conditions) - and recommend that such user-defined / vendor-defined values should ideally link to an online definition of what they mean.

shalikasingh commented 3 years ago

Hi @CraigRe,

Have we already included in the draft what type attribute of the Sensor report expects?

If not, we can add details in the draft and close the issue to save time on call. Let us know if any help is required with the content.

FYI: @mgh128

CraigRe commented 3 years ago

@CraigRe include expected values of SAT/MT/custom URI.