This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Datatypes R2 Issue 56"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) m (→Introduction: typo) |
|||
| (3 intermediate revisions by one other user not shown) | |||
| Line 2: | Line 2: | ||
== Introduction == | == Introduction == | ||
| − | Add description what | + | EN.use has a number of use codes. One of the use codes is SRCH, which has only a minimalistic description that leads to implementation questions. |
| + | |||
| + | Add description what SRCH means in practical terms, this should at least contain a description that "*" can be used at the end of a string to denote a random sequence of characters. | ||
? backward compatible. | ? backward compatible. | ||
| + | |||
| + | {{INM Motion|Remove the SRCH use code from the EN datatype. Mark Tucker/Lee ??, 9-0-0, INM TC WGM January 2007}} | ||
| + | There is no use-case for 'storing' names/addresses with a SRCH use-code, as it is query specific. | ||
| + | :In other words, SRCH is no longer a desirable feature for EN. A "flag" to indicate that something is SRCH should not be part of the datatype spec, but should be solved in a different manner. | ||
| + | :Also see [[Datatypes R2 Issue 62]] | ||
== Discussion == | == Discussion == | ||
| + | Lloyd: There is DEFINITELY a use for storing phonetic and Soundex representations of a name in person registries (and even correcting them). These were not added for querying | ||
| + | I believe the usecase for SRCH | ||
== Links == | == Links == | ||
Back to [[Data Types R2 issues]] | Back to [[Data Types R2 issues]] | ||
Latest revision as of 02:44, 17 April 2007
Data Types Issue 56: SRCH semantics
Introduction
EN.use has a number of use codes. One of the use codes is SRCH, which has only a minimalistic description that leads to implementation questions.
Add description what SRCH means in practical terms, this should at least contain a description that "*" can be used at the end of a string to denote a random sequence of characters.
? backward compatible.
There is no use-case for 'storing' names/addresses with a SRCH use-code, as it is query specific.
- In other words, SRCH is no longer a desirable feature for EN. A "flag" to indicate that something is SRCH should not be part of the datatype spec, but should be solved in a different manner.
- Also see Datatypes R2 Issue 62
Discussion
Lloyd: There is DEFINITELY a use for storing phonetic and Soundex representations of a name in person registries (and even correcting them). These were not added for querying
I believe the usecase for SRCH
Links
Back to Data Types R2 issues
