Difference between revisions of "Datatypes R2 Issue 11"
m (→Discussion: signed) |
|||
| Line 21: | Line 21: | ||
== Links == | == Links == | ||
Back to [[Data Types R2 issues]] | Back to [[Data Types R2 issues]] | ||
| + | |||
| + | == Skype == | ||
| + | |||
| + | [4:23:32 PM] Grahame Grieve says: ADXP and ENXP from SC. I'm bothered by this. Should we make constraints concerning which part types are allowed to be coded? | ||
| + | [4:23:32 PM] Grahame Grieve says: I would propose: | ||
| + | [4:24:43 PM] Grahame Grieve says: EN -> PFX and SFX | ||
| + | [4:25:52 PM] Grahame Grieve says: ADXP -> UNIT, DINST, DMOD, STTYP, CNT, STA | ||
| + | [4:27:25 PM] Grahame Grieve says: I guess the thing is why anyone would care. Since the text has to be present, you could generally safely ignore the encoding anyway. But there must be some point to the encoding or we wouldn't have been pestered for it. | ||
| + | [4:28:14 PM] Grahame Grieve says: I recall doing the pestering myself earlier, but maybe I've mellowed. Who cares if it's encoded? The only point to me is if I can actually impose a standard terminology on the string content, and that's the one thing we haven't done. | ||
| + | [8:26:01 PM] Charlie McCay says: I agree -- coding only makes sense if some receivers in some contexts can rely on it being there and being right -- for everyone else it is noise and another way to get the content wrong. I assume that the use cases are datatype flavors - I see it for address parts but agree that the case for names has not been made on the wiki. The intended use will need to be made clear in the Guide. | ||
Revision as of 22:27, 29 May 2007
Contents
Data Types Issue 11: Derive ADXP and ENXP from SC
Introduction
Address and Name parts should allow codes. Countries, states, delivery types, name prefixes and name suffixes may all have associated codes
? backward compatible.This element will be semantically backward compatible. However, making any schema change has the potential to break implementations which use tight schema validation
PM, PA
Discussion
Just derive from SC instead of ST
Grahame is having second thoughts, Charlie McKay seemed to agree. And I certainly do to. I don't think there is a real use case for this. It's just complicated fluff. Gschadow 11:16, 27 May 2007 (CDT)
Resolution
Passed in INM 30/4/2007: Motion to Derive ADXP and ENXP from SC instead of ST
Links
Back to Data Types R2 issues
Skype
[4:23:32 PM] Grahame Grieve says: ADXP and ENXP from SC. I'm bothered by this. Should we make constraints concerning which part types are allowed to be coded? [4:23:32 PM] Grahame Grieve says: I would propose: [4:24:43 PM] Grahame Grieve says: EN -> PFX and SFX [4:25:52 PM] Grahame Grieve says: ADXP -> UNIT, DINST, DMOD, STTYP, CNT, STA [4:27:25 PM] Grahame Grieve says: I guess the thing is why anyone would care. Since the text has to be present, you could generally safely ignore the encoding anyway. But there must be some point to the encoding or we wouldn't have been pestered for it. [4:28:14 PM] Grahame Grieve says: I recall doing the pestering myself earlier, but maybe I've mellowed. Who cares if it's encoded? The only point to me is if I can actually impose a standard terminology on the string content, and that's the one thing we haven't done. [8:26:01 PM] Charlie McCay says: I agree -- coding only makes sense if some receivers in some contexts can rely on it being there and being right -- for everyone else it is noise and another way to get the content wrong. I assume that the use cases are datatype flavors - I see it for address parts but agree that the case for names has not been made on the wiki. The intended use will need to be made clear in the Guide.
