search

gs1 / EPCIS

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

[REST] GS1-EPC-Format clean up reflecting latest agreements #388

Closed jmcanterafonseca-iota closed 2 years ago

jmcanterafonseca-iota commented 2 years ago

@domguinard @sboeckelmann @mgh128 please could you r?

@mgh128 if the server does not announce anything i.e. it does not provide any value for GS1-EPC-Format in the response to an OPTIONS request, is the client to understand that Always_GS1_Digital_Link is the server capability?

jmcanterafonseca-iota commented 2 years ago

Thank for the review @mgh128 . Probably I have removed it from more places than really needed but we need to clarify:

mgh128 commented 2 years ago

Hi @jmcanterafonseca-iota

When creating a query do you specify the desired GS1-EPC-Format or do you actually specify it when executing the query through the. /queries/{queryName}/events method? Does the latter override the former? When listing all queries how do I know what is the EPCIS-Format of each query?

I think that if GS1-EPC-Format is specified for /queries/{queryName}/events then it should override the value specified for the query. Not sure how we determine the value of GS1-EPC-Format that was specified when defining the query - unless there's an existing response object we can extend.

When creating a Subscription do you need to specify the GS1-EPC-Format in the POST header ... ? Or is it just the one from the query? If the latter I could not have Subscriptions bound to the same query but offering the data using different EPC Formats. If the former, when listing all the subscriptions how do you differentiate what is the EPCIS Format bound to each Subscription ?

A query could have multiple subscribers / multiple subscriptions, each with different preferences about GS1-EPC-Format, so it sounds as though GS1-EPC-Format needs to be specified when configuring the subscription rather than when defining the query. That might imply that GS1-EPC-Format should not be specified when defining the query and that /queries/{queryName}/events is an appropriate place to specify a value for GS1-EPC-Format

Probably here we are having the same problem as with Capture-Error-Behaviour and we may need to add an additional field to the payloads ...

jmcanterafonseca-iota commented 2 years ago

I thought we discussed last week and/or the previous week that a server response value of something like 'Any_format_supported' could let a server indicate that it could support either format (e.g. GS1 Digital Link URI or EPC URN, CBV Web URI vs CBV URN). I'm not seeing that reflected in this pull request.

my understanding is that No_Preference is equivalent to Any_format_supported ....

jmcanterafonseca-iota commented 2 years ago

@mgh128 please could you re-review this Pull Request. I think I have captured all agreements from the call

Thanks!

mgh128 commented 2 years ago

Hi @jmcanterafonseca-iota I've just reviewed and merged PR #390 .
When now reviewing PR #388 it's showing conflicts at lines for these two headers within 200TopLevelOrEventTypeSubResource:

     GS1-EPC-Format:
      $ref: '#/components/headers/GS1-EPC-Format'
    GS1-CBV-XML-Format:
      $ref: '#/components/headers/GS1-CBV-XML-Format'

Can I assume the PR #390 superseded the conflicts showing for PR #388 - and if so, could you close or withdraw PR#388 or otherwise advise what should be done? Thanks! - Mark

jmcanterafonseca-iota commented 2 years ago

@mgh128 the conflict has been solved, the same change you mentioned was in both PRs and now has been reconciled

ready to be merged if you deem it correct

mgh128 commented 2 years ago

Thanks - I've merged these.