Difference between revisions of "OO CR138-761 - LWE and LNE Data Types"
Riki merrick (talk | contribs) |
Riki merrick (talk | contribs) |
||
| Line 22: | Line 22: | ||
== Discussion == | == Discussion == | ||
| − | Feb 27 | + | Feb 27 2014: Review of this CR reveals that the requested datatypes do not seem to be properly defined - we will need ore time for review, but initial thoughts are: How come repeating OBX-5 fields(allowed in the base standard) don't cover this use case? It also is targeting display by receiver, which is not the goal of messaging We do have datatypes for numeric array and multi-axial array however. |
| − | Review of this CR reveals that the requested datatypes do not seem to be properly defined - we will need ore time for review, but | ||
| − | How come repeating OBX-5 fields(allowed in the base standard) don't cover this use case? | ||
| − | It also is targeting display by receiver, which is not the goal of messaging | ||
| − | We do have datatypes for numeric array and multi-axial array however. | ||
| − | Next steps: Riki to reach out to see, when Clem | + | Next steps: Riki to reach out to see, when Clem McDonald can join the call to further discuss this use case. Should OO find this use case needs support, then the document needs to be further fleshed out and should be sent to 1. Vocab WG, because during the v2/v3 tables harmonization project they discovered an issue with including the coding strength in the the dataytpe definition. 2. this is in the end an proposal to InM, as they govern the datatypes |
| − | Should OO find this use case needs support, then the document needs to be further fleshed out and should be sent to | ||
| − | 1. Vocab WG, because during the v2/v3 tables harmonization project they discovered an issue with including the coding strength in the the dataytpe definition. | ||
| − | 2. this is in the end an proposal to InM, | ||
== Recommended Action Items == | == Recommended Action Items == | ||
| + | Feb 27 2014: Riki to reach out to see, when Clem McDonald can join the OO WG call to discuss further | ||
== Resolution == | == Resolution == | ||
Revision as of 01:52, 28 February 2014
Return to OO Change Requests page.
| Submitted by: Clem McDonald | Revision date: <<Revision Date>> |
| Submitted date: 11 September 2013 | Change request ID: OO CR138-761 |
| Standard/IG: Standard | Artifact ID, Name: <<Artifact ID, Name>> |
Issue
See File:OO CR 138-761.doc for problem definition and proposal.
Recommendation
Rationale
Discussion
Feb 27 2014: Review of this CR reveals that the requested datatypes do not seem to be properly defined - we will need ore time for review, but initial thoughts are: How come repeating OBX-5 fields(allowed in the base standard) don't cover this use case? It also is targeting display by receiver, which is not the goal of messaging We do have datatypes for numeric array and multi-axial array however.
Next steps: Riki to reach out to see, when Clem McDonald can join the call to further discuss this use case. Should OO find this use case needs support, then the document needs to be further fleshed out and should be sent to 1. Vocab WG, because during the v2/v3 tables harmonization project they discovered an issue with including the coding strength in the the dataytpe definition. 2. this is in the end an proposal to InM, as they govern the datatypes
Recommended Action Items
Feb 27 2014: Riki to reach out to see, when Clem McDonald can join the OO WG call to discuss further
