Stream: fhircast-github
Topic: fhircast-docs / Issue #95 May 2019 Ballot Comment: Client...
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot opened Issue #95
## May 2019 Ballot Comment: Clients may or may not use a message queue, this isn't part of the spec.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Request
Url:
Type: NEG :exclamation: Correction
In Person requested: Yes :bust_in_silhouette:Summary: Clients may or may not use a message queue, this isn't part of the spec.
Comment: FHIRcast doesn't dictate client's internal behavior or software architecture. The use of lower-case "should" is confusing because it's unclear if this is a requirement or not.
Existing wording: The timestamp should be used by subscribers to establish message affinity through the use of a message queue.
Proposed wording: The timestamp can be used by subscribers to establish message affinity through the use of a message queue.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot labeled Issue #95
## May 2019 Ballot Comment: Clients may or may not use a message queue, this isn't part of the spec.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Request
Url:
Type: NEG :exclamation: Correction
In Person requested: Yes :bust_in_silhouette:Summary: Clients may or may not use a message queue, this isn't part of the spec.
Comment: FHIRcast doesn't dictate client's internal behavior or software architecture. The use of lower-case "should" is confusing because it's unclear if this is a requirement or not.
Existing wording: The timestamp should be used by subscribers to establish message affinity through the use of a message queue.
Proposed wording: The timestamp can be used by subscribers to establish message affinity through the use of a message queue.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot labeled Issue #95
## May 2019 Ballot Comment: Clients may or may not use a message queue, this isn't part of the spec.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Request
Url:
Type: NEG :exclamation: Correction
In Person requested: Yes :bust_in_silhouette:Summary: Clients may or may not use a message queue, this isn't part of the spec.
Comment: FHIRcast doesn't dictate client's internal behavior or software architecture. The use of lower-case "should" is confusing because it's unclear if this is a requirement or not.
Existing wording: The timestamp should be used by subscribers to establish message affinity through the use of a message queue.
Proposed wording: The timestamp can be used by subscribers to establish message affinity through the use of a message queue.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot labeled Issue #95
## May 2019 Ballot Comment: Clients may or may not use a message queue, this isn't part of the spec.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Request
Url:
Type: NEG :exclamation: Correction
In Person requested: Yes :bust_in_silhouette:Summary: Clients may or may not use a message queue, this isn't part of the spec.
Comment: FHIRcast doesn't dictate client's internal behavior or software architecture. The use of lower-case "should" is confusing because it's unclear if this is a requirement or not.
Existing wording: The timestamp should be used by subscribers to establish message affinity through the use of a message queue.
Proposed wording: The timestamp can be used by subscribers to establish message affinity through the use of a message queue.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot edited Issue #95
## May 2019 Ballot Comment: Clients may or may not use a message queue, this isn't part of the spec.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Request
Url:
Type: NEG :exclamation: Correction
In Person requested: Yes :bust_in_silhouette:Summary: Clients may or may not use a message queue, this isn't part of the spec.
Comment: FHIRcast doesn't dictate client's internal behavior or software architecture. The use of lower-case "should" is confusing because it's unclear if this is a requirement or not.
Existing wording: The timestamp should be used by subscribers to establish message affinity through the use of a message queue.
Proposed wording: The timestamp can be used by subscribers to establish message affinity through the use of a message queue.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 07 2019 at 21:26):
isaacvetter commented on Issue #95
During conversation at the Montreal, May 2019 working group meeting, @wbdr, @wmaethner, @NiklasSvenzen and myself talked through this issue and would like to propose:
Proposed resolution: Persuasive with Mod
Proposed wording: The timestamp MAY be used by subscribers to establish message affinity through the use of a message queue.
Github Notifications (FHIRcast) (May 07 2019 at 21:26):
isaacvetter assigned Issue #95
## May 2019 Ballot Comment: Clients may or may not use a message queue, this isn't part of the spec.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Request
Url:
Type: NEG :exclamation: Correction
In Person requested: Yes :bust_in_silhouette:Summary: Clients may or may not use a message queue, this isn't part of the spec.
Comment: FHIRcast doesn't dictate client's internal behavior or software architecture. The use of lower-case "should" is confusing because it's unclear if this is a requirement or not.
Existing wording: The timestamp should be used by subscribers to establish message affinity through the use of a message queue.
Proposed wording: The timestamp can be used by subscribers to establish message affinity through the use of a message queue.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 30 2019 at 03:22):
isaacvetter labeled Issue #95 (assigned to isaacvetter):
## May 2019 Ballot Comment: Clients may or may not use a message queue, this isn't part of the spec.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Request
Url:
Type: NEG :exclamation: Correction
In Person requested: Yes :bust_in_silhouette:Summary: Clients may or may not use a message queue, this isn't part of the spec.
Comment: FHIRcast doesn't dictate client's internal behavior or software architecture. The use of lower-case "should" is confusing because it's unclear if this is a requirement or not.
Existing wording: The timestamp should be used by subscribers to establish message affinity through the use of a message queue.
Proposed wording: The timestamp can be used by subscribers to establish message affinity through the use of a message queue.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Jun 18 2019 at 15:31):
wmaethner labeled Issue #95 (assigned to isaacvetter):
## May 2019 Ballot Comment: Clients may or may not use a message queue, this isn't part of the spec.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Request
Url:
Type: NEG :exclamation: Correction
In Person requested: Yes :bust_in_silhouette:Summary: Clients may or may not use a message queue, this isn't part of the spec.
Comment: FHIRcast doesn't dictate client's internal behavior or software architecture. The use of lower-case "should" is confusing because it's unclear if this is a requirement or not.
Existing wording: The timestamp should be used by subscribers to establish message affinity through the use of a message queue.
Proposed wording: The timestamp can be used by subscribers to establish message affinity through the use of a message queue.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Jun 18 2019 at 15:31):
wmaethner commented on Issue #95:
## :landline: II Working Group Vote (6-18-2019)
Block vote@isaacvetter moved the following disposition, seconded by Ricardo Quintano Neira
Disposition: Persuasive
Disposition Comment: Will fix as described in the issue comments or by the commenter:+1: For: 10
:expressionless: Abstain: 2
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (Jun 18 2019 at 15:40):
wmaethner edited a comment on Issue #95:
## :landline: II Working Group Vote (6-18-2019)
Block vote@isaacvetter moved the following disposition, seconded by Ricardo Quintano Neira
Disposition: Persuasive with mod
Disposition Comment: Will fix as described in the issue comments or by the commenter:+1: For: 10
:expressionless: Abstain: 2
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (Jul 02 2019 at 18:55):
wmaethner labeled Issue #95 (assigned to isaacvetter):
## May 2019 Ballot Comment: Clients may or may not use a message queue, this isn't part of the spec.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Request
Url:
Type: NEG :exclamation: Correction
In Person requested: Yes :bust_in_silhouette:Summary: Clients may or may not use a message queue, this isn't part of the spec.
Comment: FHIRcast doesn't dictate client's internal behavior or software architecture. The use of lower-case "should" is confusing because it's unclear if this is a requirement or not.
Existing wording: The timestamp should be used by subscribers to establish message affinity through the use of a message queue.
Proposed wording: The timestamp can be used by subscribers to establish message affinity through the use of a message queue.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Sep 11 2019 at 20:52):
wmaethner closed Issue #95 (assigned to isaacvetter):
May 2019 Ballot Comment: Clients may or may not use a message queue, this isn't part of the spec.
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Event Notification Request
Url:
Type: NEG :exclamation: Correction
In Person requested: Yes :bust_in_silhouette:Summary: Clients may or may not use a message queue, this isn't part of the spec.
Comment: FHIRcast doesn't dictate client's internal behavior or software architecture. The use of lower-case "should" is confusing because it's unclear if this is a requirement or not.
Existing wording: The timestamp should be used by subscribers to establish message affinity through the use of a message queue.
Proposed wording: The timestamp can be used by subscribers to establish message affinity through the use of a message queue.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Last updated: Apr 12 2022 at 19:14 UTC
