RE: QC certificates and Nationality

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Bob,

In an ideal world, I too would prefer a single INTEGER type.

But we are living in a world leaning toward XML, where non-validated
character fields reign :-).  How many implementations today actually
contain a table of 3166 digraphs, and how many just accept any two
PrintableString characters for the CountryName attribute?

Look at it as an opportunity to differentiate - if you already support
validation of digraphs, how much harder would it be to extend your
implementation to handle a table of 3-tuples, and do equivalence
matching for free?  IMHO, going from unconstrained 2-character strings
to validated 3166 digraphs is the hard part, and extending that to
handle trigraphs is trivial.

It would make sense to make the QC constraint a bit more specific,
to prevent the use of ASCII numbers:

     (CONSTRAINED BY { -- IS 3166 digraphs and trigraphs only })

Regards,
  Dave



>   [...]
>
> If I had a choice, I would prefer a single attribute type, namely 
> INTEGER, since such things are obviously the easiest to look 
> up in a simple table without having to use either serial 
> comparisons or some sort of searching algorithm such as 
> a hash.
> 
> But I don't like having to be forced to implement three different 
> ways to  input and output the same information, or worse yet 
> to count the number of characters in order to determine which 
> table of allowable codes to use when validating the input.
> 
> Guess I'm still unconvinced.
> 
> Regards,
> 
> Bob