1.  Indicator. Type.  Both OAGi and ATG2 have translated the CCT Indicator. Type into the xsd:boolean built-in type.  Furthermore, the list of valid values has been reduced to "false" or "true" (other values allowed by xsd:boolean are "TRUE", "FALSE", "0", "1").  The reasoning is that since each of these sets of values does not change the semantics of what is being communicated, there should not be multiple representations for the same semantic concept.  The pair "true", "false" was selected because it was felt that it best conformed to existing usage of booleans.  It has been argued that "0", "1" would be a more international representation since it is not language specific.  What do you think?

NOTE:  It has also been argued that Indicator. Type should be anything with two, and only two valid values which would prevent it from being defined as xsd:boolean.  I'd like to set aside that argument for now and assume we are only dealing with xsd:boolean.

2.  Identifier Lists.  The ATG2 NDR has introduced the concept of "Identifier Lists".  Line 530 states "In those cases where identifier schemes mimic the functionality of code lists, reusable identifier lists schema modules will be created to minimize the impact of identifier list changes on root and other reusable schema.  Each reusable identifier list schema module will contain enumeration values for codes and code values".  Should OAGIS implement Identifier Lists?  If so, what rules or guidelines should apply in order to determine if something is an Identifier List or not?

3.  Code vs Identifier.  I put this one last so you wouldn't immediately delete this email.  Do we now have some general consensus about how to distinguish codes from identifiers and vice versa?  Has anyone taken all of the material written to date and summarized them into a clear set of rules/guidelines?

For example, I think there is general agreement that Codes are "relatively" static and are "usually" maintained by some authorized agency.  They are a shortened/encoded/abbreviated representation of some "thing", normally text, and usually of the same consistent length within a code list.  If we can capture these attributes/characteristics as a set of rule, guidelines, or some kind of checklist, I'm sure it would help a lot of people trying to implement CCTS.

Thanks,

garret