nc:ContactInformationIsEveningIndicator nc:ContactInformationIsNightIndicator The last on the above list are perhaps replaced by ContactInformationAvailibilityCode. To preserve the greatest level of compatibility’ or to at least minimize the version migration challenges and costs, then at a minimum, all ‘backward ECF4 supported information should also be supported in ECF5. There may be ECF4 implementations that are unknown to the TC that utilize elements which have been removed in ECF5. If there are compelling and/or necessary reasons for replacing nc:PersonContactInformationAssociationType and nc:OrganizationContactInformationAssociationType with just nc:ContactInformationAssociationType, then the person contact specific elements (i.e. nc:ContactInformationIsHomeIndicator, and nc:ContactInformationIsWorkIndicator, could be accessed through a ContactInformationAssociationAugmentationPoint, such as PersonContactInformationAssociationAugmentation. Both nc:ContactInformation and nc:ContactInformationAssociation are required as the actual contact information is provided in nc:ContactInformation while the indicators (home, work, etc.) are provided in nc:ContactInformationAssociation. Other Augmentation Many elements, such as EntityPerson, contain two augmentation points (e.g. structures:ObjectAugmentationPoint and nc:PersonAugmentationPoint). When and how is structures:ObjectAugmentationPoint used? structures:ObjectAugmentationPoint is included in all NIEM complete types. There is no removing it. DocumentIdentification cardinality ECF 4.01 permits unlimited nc:DocumentIdentification elements in CoreFilingMessage. In ECF5 working draft 10, the limit in FilingMessage is at most one. Also, in ECF4, nc:DocumentIdentification is optional in CoreFilingMessage. In ECF5 it is mandatory in FilingMessage. Why has this changed? As used in FilingMessage, DocumentIdentification is a Identifier’ (see section 6.2.6 Filing Identifiers). ‘Filing
nc:ContactInformationIsEveningIndicator nc:ContactInformationIsNightIndicator The last on the above list are perhaps replaced by ContactInformationAvailibilityCode. To preserve the greatest level of ‘backward compatibility’ or to at least minimize the version migration challenges and costs, then at a minimum, all ECF4 supported information should also be supported in ECF5. There may be ECF4 implementations that are unknown to the TC that utilize elements which have been removed in ECF5. If there are compelling and/or necessary reasons for replacing nc:PersonContactInformationAssociationType and nc:OrganizationContactInformationAssociationType with just nc:ContactInformationAssociationType, then the person contact specific elements (i.e. nc:ContactInformationIsHomeIndicator, and nc:ContactInformationIsWorkIndicator, could be accessed through a ContactInformationAssociationAugmentationPoint, such as PersonContactInformationAssociationAugmentation. Both nc:ContactInformation and nc:ContactInformationAssociation are required as the actual contact information is provided in nc:ContactInformation while the indicators (home, work, etc.) are provided in nc:ContactInformationAssociation. Other Augmentation Many elements, such as EntityPerson, contain two augmentation points (e.g. structures:ObjectAugmentationPoint and nc:PersonAugmentationPoint). When and how is structures:ObjectAugmentationPoint used? structures:ObjectAugmentationPoint is included in all NIEM complete types. There is no removing it. DocumentIdentification cardinality ECF 4.01 permits unlimited nc:DocumentIdentification elements in CoreFilingMessage. In ECF5 working draft 10, the limit in FilingMessage is at most one. Also, in ECF4, nc:DocumentIdentification is optional in CoreFilingMessage. In ECF5 it is mandatory in FilingMessage. Why has this changed? As used in FilingMessage, DocumentIdentification is a ‘Filing Identifier’ (see section 6.2.6 Filing Identifiers).
ECF5%20Spec%20Considerations-5%20-%20jec%20responses.docx