© 2019 The Calendaring and Scheduling Consortium, Inc.
This document is not a CalConnect Standard. It is distributed for review and comment, and is subject to change without notice and may not be referred to as a Standard. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the address below.
The Calendaring and Scheduling Consortium, Inc.
4390 Chaffin Lane
McKinleyville
California 95519
United States of America
copyright@calconnect.org
www.calconnect.org
The Calendaring and Scheduling Consortium (“CalConnect”) is a global non-profit organization with the aim to facilitate interoperability of collaborative technologies and tools through open standards.
CalConnect works closely with international and regional partners, of which the full list is available on our website ().
The procedures used to develop this document and those intended for its further maintenance are described in the CalConnect Directives.
In particular the different approval criteria needed for the different types of CalConnect documents should be noted. This document was drafted in accordance with the editorial rules of the CalConnect Directives.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CalConnect shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be provided in the Introduction.
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
This document was prepared by Technical Committee VCARD.
Addresses are among the most commonly exchanged information on the Internet, and the interchange of them is crucial to a number of Internet applications, such as electronic commerce, contact exchange, non-postal deliveries, as well as location scheduling.
Yet, addresses can mean much more than just geolocation information:
as an identity, such as an office address;
as reference points (waypoints) in routing information; and
as a delivery point.
The interchange of addresses require a common structure of address data. For instance of a software application in need of user input of address information, users need assistance from the application to enter the correct format and structure of the address for it to be machine readable and interoperable among different machines or systems which process the address data.
This document specifies a set of data models that focuses on enabling software applications the digital interchange of address profiles, address instances and instructions for their input and display suitable for machine encoding of address information. These models are called the “Address Interchange Object” (“AXO”) models.
Furthermore, a registry mechanism is defined to ensure the address profiles can be made publicly available.
This standard complements the other parts in the family of ISO 19160 standards:
ISO 19160-5 focuses on the rendering of addresses for different devices with a focus on their representations on maps, virtual and augmented reality. This document focuses on providing an interoperable data model for the interchange and storage of address profiles and addresses, as well as the input and rendering of compliant addresses in a normalized manner. This approach results into a scheme that can be understood across the spectrum of address consumers, including humans, applications, devices and systems.
The lifecycle of an address entry exchanged on the Internet typically starts with manual input of a human actor. This data, structured or unstructured, is then submitted to an Internet-connected application, and the application may in turn transmit this information to other applications or external parties on behalf of the user who provided the address.
This transmission is usually performed to fulfil service delivery to the user. Within the process, there may be machine-human interactions that require display of the address in human-readable form, as well as machine-to-machine interactions on the address, such as for data validation.
Additional caution shall be placed on the accuracy (or lack thereof) of human input addresses. While an address specified by a human actor may unambiguously distinguish a location, there may be intention or unintentional omissions or additions to an “official” address (if there was one).
Attributes of the object which the address points to are considered
out of scope of this document, including the AddressableObject model
specified in
While considered orthogonal to the AXO models, AddressableObject and other simliar models can easily be used together with the AXO models.
In a navigation map, an AXO address can point to an addressable object, in which provides a list of its extant facilities.
This document specifies a set of data models suitable for machine encoding of address information, called the “Address Interchange Object” (“AXO”) models, and the usage of them.
Specifically, this document provides:
data models for digital storage and interchange of address profiles
conforming to
data models for digital storage and interchange of addresses conforming to a specific address profile;
data models for entry and display templates for entering and displaying addresses conforming to the profile and encoding rules above; and
the management and operations of a register of address profiles conforming to this document.
Addressability, and features provided within the object which the address
points to, is not described in this document. Specifically, the
AddressableObject from
For the purposes of this document, the terms and definitions
given in
provenance, source(s) and production process(es) used in producing a resource
definition of the subset of a user’s environment that depends on language and cultural conventions
The notes given in
set of one or more base standards or subsets of base standards, and, where applicable, the identification of chosen clauses, classes, options and parameters of those base standards, that are necessary for accomplishing a particular function
organization or individual that created, accumulated, maintained and used records
specification of a value domain with operations allowed on values in this domain
A data type that has no super type. The primitive data type of a data type is the data type itself, if the data type has no super type, and otherwise the primitive data type of the super type of the data type.
an address compliant to an interchange address class profile
marking on a profile-compliant address to indicate what it is capable of
specification of layout and positioning of address components for interchange addresses
address layout template (
address layout template (
entity that processes profile-compliant addresses
entity that distributes address profiles
the string of bits resulting from the signature process
a secret data item specific to an entity and usable only by this entity in the signature process
a data item which is mathematically related to an entity’s
signature key (
a value (distinguishable from all other such values) which is associated with an object
symbol that uniquely identifies a particular language
set of graphic characters used for the written form of one or more languages
combination of characters used to represent the name of a script (
uniform resource identifier
This part of ISO 19160-6 defines four classes of requirements and
conformance.
To conform to this standard, an address profile register shall satisfy all of
the requirements specified for a register in
Any machine-readable description of an ISO 19160-6 AddressProfile for which conformance
is claimed shall pass all the requirements described in the abstract test suite in
Any machine-readable description of an ISO 19160-6 AddressClassProfile for which
conformance is claimed shall pass all the requirements described in the
abstract test suite in
Any machine-readable description of an ISO 19160-6 AddressComponentProfile for
which conformance is claimed shall pass all the requirements described in the
abstract test suite in
Any machine-readable description of an ISO 19160-6 ProfileCompliantAddress for
which conformance is claimed shall pass all the requirements described in the
abstract test suite in
Any machine-readable description of an ISO 19160-6
ProfileCompliantAddressComponent for which conformance is claimed shall pass
all the requirements described in the abstract test suite in
Any machine-readable description of an ISO 19160-6 InterchangeAddressClassProfile for
which conformance is claimed shall pass all the requirements described in the
abstract test suite in
Any FormTemplate in InterchangeAddressClassProfile model for which
FormTemplate conformance is claimed shall pass the requirements
described in the abstract test suite in
Any DisplayTemplate in InterchangeAddressClassProfile model for
which DisplayTemplate conformance is claimed shall pass the
requirements described in the abstract test suite in
The ISO address profile registry will be managed with version control software, publicly available with an API and a graphical user interface, such as a web-based interface, to satisfy both programatic and human use for the dissemination, display and management of the registry.
The ISO address profile register is a non-hierarchical register. References to principal registers and sub-registers are excluded from this document.
This address profile registry follows the requirements specified in
Rules for managing a register of geographical information items, including the submission of information, are found in
Reference to the
The roles and responsibilities of the register owner, register manager, submitting organizations,
control body, registry manager and register user are set out in
Requirement 1 [ɳ1]: The register owner shall set terms and conditions regarding different levels of access to the register and making the contents available to the public. In addition, the register owner shall specify the time period in which the approval process shall be completed.
Requirement 2 [ɳ2]: The register owner shall appoint a register manager. A register owner may serve as the register manager for any register that it has established or it may appoint another organization to serve as the register manager.
Requirement 3 [ɳ3]: The register owner shall decide whether a control body is required for the register and if so appoint the control body. The register owner may serve as the control body for any register that it has established or it may delegate that role to a subgroup within the organization or to the register manager.
Requirement 4 [ɳ4]: A register owner shall specify the criteria that determine which organizations may act as submitting organizations.
Requirement 5 [ɳ5]: The register owner shall clarify the process for a submitting organization to appeal decisions of the control body (if such a body is appointed). The register owner may establish a procedure for such a process. The specification of this procedure shall include appropriate time limits for completion of the process. An alternative solution may be for a submitting organization to resubmit a new proposal with changes or a better justification.
Requirement 6 [ɳ6]: A register manager shall manage a register in conformance with
Requirement 7 [ɳ7]: Upon request, the register manager shall distribute an information package containing a description of the register and how to submit proposals for changes to the content of the register. The information package shall describe what proposed changes to the content may be considered to be substantive.
Requirement 8 [ɳ8]: The register manager shall accept proposals from submitting organizations and manage the proposals as specified in
Requirement 9 [ɳ9]: The register manager shall determine whether a submitting organization is qualified in accordance with the criteria established by the register owner.
Requirement 10 [ɳ10]: If a control body is appointed, it shall accept proposals from the register manager and render a decision regarding each proposal within the time limits specified by the register owner.
Requirement 11 [ɳ11]: A registry manager shall ensure the integrity of any register held in the registry and shall provide means for electronic access to the registry for register managers, control body members, and register users.
Requirement 12 [ɳ12]: Register managers shall consider the requirements of different categories of users in selecting methods for publishing the content of a register.
Requirement 13: The ISO address profile register shall have a publicly available record of changes where historical content shall remain publicly available.
Submitting organizations for the ISO address profile register consist of organizations and/or persons responsible for defining and maintaining address profiles.
The unmodified
Requirement 14 [ɳ13]: Every register shall have a technical document describing the item classes to be registered. For the ISO address profile register that technical document is this document.
Requirement 15 [ɳ14]: Items shall be individually managed, moving through a set of well-defined states. Information about the temporal history of each item shall be maintained.
Requirement 16 [ɳ16]: A clarification shall not cause any substantive semantic or technical change to a registered item.
Requirement 17 [ɳ17]: Clarification shall be accomplished by updating the existing item in the register. The clarification shall be recorded with a justification of the change and the date on which the register transaction was made.
Requirement 18 [ɳ19]: Retirement shall be accomplished by leaving the item in the register, having its status changed to retired, and including the date on which the register transaction was made.
Requirement 19 [ɳ21]: The register manager shall review proposals received from third parties for completeness and return proposals to the submitting organization if the proposal is incomplete or if the submitting organization is not qualified, else initiate the approval process.
Requirement 20 [ɳ22]: The approval process shall be completed within the time period specified by the register owner.
Requirement 21 [ɳ23]: A registry manager shall ensure that information about valid, invalidated, superseded, or retired items in the register is readily available to users.
The
Requirement 22 [ɳ15]: If an item is superseded by another item, the date the succession occurred shall be captured, along with references to and from the item that superseded it. At any given time, only one item in the series should be “valid”. The requirement that only one item in the series is “valid” is removed.
Requirement 23 [ɳ20]: If a register item is deemed to be no longer suitable for the use in the production of new data and has been superseded by a new register item, the original item shall remain in the register, shall have its status changed to superseded, have a reference to the item(s) that superseded it, including the date on which the register transaction was made. The option of removing a superseded item from the register is removed.
Requirement 24 [ɳ18]: If an item in a register is found to have substantive error, it shall be left in the register, have its status changed to invalid, have a reference to the item(s) that replaced it, and have the date when the register transaction was made.
The option of removing an invalidated item from the register is removed.
Requirement 25: The ISO address profile registry shall follow
The ISO address profile register shall conform to the core register schema in
Requirement 26 [ɳ24]: The core register shall conform to the register schema as specified in UML in
Requirement 27 [ɳ25]: The attribute identifier that designates an item class held in a register that conforms to
Requirement 28 [ɳ26]: The attribute itemIdentifier is represented as a CharacterString that is used to uniquely denote that item within an item class and is intended for information processing. Once a value has been assigned, it shall not be reused. The class/identifier union shall be unique within the register.
Practical usage of AXO models relies on the establishment of an address profile registry.
This clause sets out specific requirements in relation with
The roles and responsibilities of the register owner, register manager, submitting organizations, control body, registry manager and register user are set out in
Data structures that are shared on the address profile registry include address profiles and their metadata in machine-readable format.
A control body is setup to manage creation of and changes to registered items at the registration authority.
Address class profiles that comply with
Submitting organizations distribute their address profiles to others through direct exchange or through a registry.
Submitting organizations can update an address profile and profiles associated with it, and re-distribute it by publishing using a new version number that supersedes the previously published one.
Applications retrieve suitable address class profiles associated with corresponding address profiles to:
render address input forms according to the profile-specified form template; or
display addresses according to the profile-specified display template.
Applications shall consider the validity period of an address class profile, and shall periodically check with the submitting organization (or the registry that the submitting organization distributes via) the latest version of the address profile.
Submitting organizations can indicate the validity period of an address class profile in the profile itself, which if the validity end date has passed, would indicate that the profile is retired.
To immediately retire an address class profile, the submitting organization shall distribute a new version of the address profile with an expired validity period.
This clause describes how a profile-compliant address is created. The desired address class profile shall be already retrieved for creating a profile-compliant address that conforms to it.
Typically, a user enters an address through an application interface that implements an input format that conforms to the interchange address class profile’s form template, such as an application that runs on an operating system or an Internet application. Such input interface may or may not provide a graphical form.
Conforming applications should not expect general users to be able to input an address with a fully-deduced structure. Immediately after input no features are marked on the interchange address.
After a user inputs an address into a structured address form, the user submits this address to the designated recipient, which could be an e-retailer, an electronic business card, or a calendar event.
The recipient or service that receives an interchange address instance either already has the interchange address class profile or should obtain the interchange address class profile definition. With the interchange address class profile, it could then display the interchange address according to the address class profile’s display template.
The recipient or service could process the address, such as to further clean up the address by improving the conformance level by fully deducing the address structure, which would add an address feature to the address instance.
To ensure that the resulting interchange address with a fully-specified structure is correct, the processor may wish to confirm with the user the resulting address, such as in the case where the address is used for shipping information. This would add the AddressFeature to the address instance.
The recipient or service could further validate the address, such as with a postal or addressing authority. This would add the AddressFeature to the interchange address written by the verifying authority.
A processor of an interchange address could add extra information such as delivery instructions or routes as associated data.
If the user already has a verified, structured address, then the service could save the effort for verifying the address. Custom address features could be added into the interchange address.
When a service no longer needs an address, the address should be disposed of.
The address profile model defined in this document consists of three major layers:
the AddressProfile model as a container of profiles of addresses and address components,
the profiles of addresses and address components, and
the addresses and address components conforming to the profiles of addresses and address components.
The AddressProfile model acts as a container of AddressClassProfiles and
AddressComponentProfiles. In general, an AddressProfile contains the
AddressClassProfiles and AddressComponentProfiles of a single country or
region, which can be represented as country code in
For addresses to conform to this standard, they and their associated address components shall conform to their corresponding AddressClassProfiles and AddressComponentProfiles.
The association between an address and an address components shall also conform to the AddressComponentSpecification defined in between the AddressClassProfile and AddressComponentProfile. Those conforming addresses and address components are ProfileCompliantAddresses and ProfileCompliantAddressComponents.
As ProfileCompliantAddress and ProfileCompliantAddressComponent extend from
Address and AddressComponent respectively, their instances will be compliant
to
This document further defines InterchangeAddressClassProfile for defining AddressClassProfiles which can be claimed as interchangeable. Addresses compliant to InterchangeAddressClassProfile will be interchangeable among humans, devices and systems with interoperability.
This clause defines a number of composite data models,
integrates and thereby requires coordination between complex precedent
standards, including
These are the common data types used within this document.
Primitive data types (PrimitiveTypes) are defined in
CharacterString
DateTime, Date, Time
Number, Integer, Decimal, Real
Vector
Boolean
Core data types (CoreTypes) are defined in
The type of written script as defined in
This is the value of language code as specified in
This is the value of country code as specified in
The type of CI_Date as defined in
The type of PT_Locale as defined in
The geographic, temporal and vertical information of EX_Extent defined in
The constraint information of MD_Constraints as defined in
The public key cryptographic algorithm used for digital signature as defined in
Represents localization metadata of the parent object.
Realized using a PT_Locale object defined in
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
locale | The locale of the parent object. | M | 1 | iso19115PT_Locale |
script | The type of written script used in the parent object. | M | 1 | iso15924Code |
writingSystem | The type of writing system used in the parent object. | M | 1 | iso24229Code |
textDirection | Indicating in which direction the text of the parent should be read. | M | 1 | TextDirectionCode |
The time interval where an object is considered valid, with a revision number for issuance date/time.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
validityBegins | The date and time when validity starts. | M | 1 | iso19115CI_Date |
validityEnds | The date and time when validity ends. | M | 1 | iso19115CI_Date |
revision | Issuance date/time. | M | 1 | iso19115CI_Date |
A cryptographic signature used to determine data integrity and validity of the object it belongs to.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
algorithm | The public key cryptographic algorithm used for this digital signature. | M | 1 | iso14888Oid |
publicKey | A reference to the actual public key used to verify the digital signature, a URI where the public key of the signer used for this signature is found. | M | 1 | Uri |
signature | The actual digital signature value encoded in Base64 format. | M | 1 | CharacterString |
An enumeration value of TextDirectionCode represents the reading direction of textual data whether it is from left to right or right to left, and from top to bottom or bottom to top.
Name | Definition |
---|---|
leftToRightTopToBottom | Indicating that text should be read left to right, and top to bottom. |
rightToLeftTopToBottom | Indicating that text should be read right to left, and top to bottom. |
leftToRightBottomToTop | Indicating that text should be read left to right, and bottom to top. |
rightToLeftBottomToTop | Indicating that text should be read right to left, and bottom to top. |
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
country | The country of which this AddressProfile represents. | O | N | iso3166Code |
An AddressClassProfile represents a profile of a ProfileCompliantAddress.
It corresponds to the concept of an AddressClass originally
expressed in
It represents additional attributes and restrictions to the ProfileCompliantAddress model. It also represents metadata for the use of the profile.
A single profile can include and support multiple types of address formats, such as a numbered street address and a “PO Box” address simultaneously. Each of these address formats is represented as an interchange address class.
The US Numbered Thoroughfare Address with this syntax can be represented as an address class profile:
* { Complete Landmark Name or Complete Place Name }
* { Complete Address Number * }
* { Complete Street Name * }
* { Complete Subaddress }
* { Complete Place Name * }
* { State Name * }
* { Zip Code }
* { Zip Plus 4 }
* { Country Name }
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
id | Unique identifier of this AddressClassProfile. | M | 1 | CharacterString |
type | Intended usage of this profile. | M | 1 | CharacterString |
description | Textual description of this profile. | M | 1 | CharacterString |
localization | The language and script used within this profile. | M | 1 | Localization |
signature | The digital signature to verify the integrity of this profile, and the identity of the publishing authority. | O | 1 | Signature |
areaApplicability | The geographic representation of which this AddressClassProfile applies to. Overlapping geographic areas are allowed across different profiles. | O | N | iso19115MD_SpatialRepresentation |
timeToLive | The maximum time interval between refreshing of this profile via an authoritative source, in seconds. | M | 1 | Integer |
validity | The period of date and time that this profile should be considered as valid. | M | 1 | Validity |
An AddressComponentProfile represents a profile of a ProfileCompliantAddressComponent,
which is extended from the AddressComponent model defined in
It represents additional attributes and restrictions to the Address model of a ProfileCompliantAddress. It also represents metadata for the use of the profile.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
key | An identifier of this AddressComponentProfile, shall be unique within the AddressProfile. | M | 1 | CharacterString |
description | Textual description of this component. | M | 1 | CharacterString |
example | A textual example to demonstrate the correct use of this component. | O | 1 | CharacterString |
An AddressComponentSpecification specifies the cardinalities between a ProfileCompliantAddress and ProfileCompliantAddressComponents.
A ProfileComplinatAddress MUST conform to this AddressComponentSpecification to specifies its components.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
maxCardinality | The maximum number of instances of the specific ProfileCompliantAddressComponent of a ProfileCompliantAddress. | M | 1 | Integer |
minCardinality | The minimum number of instances of the specific ProfileCompliantAddressComponent of a ProfileCompliantAddress. | M | 1 | Integer |
An AttributeProfile represents name, cardinalities and value type of an attribute in a model that complies with a profile that includes this AttributeProfile.
If it represents an attribute that has been previously defined, e.g. an
attribute in Address model defined in
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
name | The name of the attribute represented by this AttributeProfile. | M | 1 | CharacterString |
minCardinality | The minimum number of occurrences of the attribute represented by this AttributeProfile. | O | 1 | Integer |
maxCardinality | The maximum number of occurences of the attribute represented by this AttributeProfile. | O | 1 | Integer |
valueType | The data type of values of the attribute represented by this AttributeProfile. | O | 1 | CharacterString |
ProfileCompliantAddress extends from the Address model defined in
A ProfileCompliantAddress MUST conform to the constraints and requirements specified in AddressClassProfile, and its associated profiles and specifications.
ProfileCompliantAddressComponent extends from the AddressComponent model
defined in
A ProfileCompliantAddressComponent MUST conform to the constraints and requirements specified in AddressComponentProfile, and its associated profiles and specifications.
This InterchangeAddressClassProfile extends from AddressClassProfile to enforce the existence of several subclasses of AttributeProfile for interchange.
It also introduces FormTemplate and DisplayTemplate to to allow the display, entry of, and the interchange of an ProfileCompliantAddress (address instance complying with an InterchangeAddressClassProfile).
The display template is used for displaying an interchange address instance belonging to an interchange address class. Generally, one address class is represented by one display template.
This section shows how an input form can be rendered according to the interchange address class.
The form template should use should also provide an example for display purposes in input (e.g., Help section).
The form template is used for displaying an input form for entry of address data into an interchange address instance. Generally, one address class is represented by one input template.
This part has no equivalence in PATDL.
AttributeProfileSignature extends from AttributeProfile to represent the signature attribute of the object it belongs to.
AttributeProfileAddressFeature extends from AttributeProfile to represent the feature attribute of the object it belongs to.
AttributeProfileValidity extends from AttributeProfile to represent the validity attribute of the object it belongs to.
Address feature represents the status of a particular aspect of an interchange address instance, as determined by an address processor. Each of the aspects may be differentiated by multiple statuses.
This is an abstract class. To represent specific features, this class should be extended upon.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
signature | Cryptographic signature used to ensure that the feature is marked by an address process trusted for verification of this feature. The signature generated shall incorporate the id attribute of the interchange address instance that owns it. | O | 1 | Signature |
When an address is first manually entered by a common person, it is unrealistic to expect this person to fully adhere to the defined structure.
The allowed values of specification levels are:
Fully structured, all components are accurately separated and cannot be further split.
Partially structured, some components may be structurally correct, but some other components are still unstructured.
Unstructured, the user has entered free-form text with no regard of structuring them.
Digital addresses entered on e-commerce sites and address books are often partially structured, with defined country, region and city, but with street addresses often unstructured.
Digital addresses for utility installations (e.g. electricity, water supplies) are often fully structured.
Therefore, an organization who accepts these addresses may wish to re-structure them or fill in any missing address components.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
value | Indicating the extent of specification of an address instance on its structure. | M | 1 | SpecificationLevelValue |
An address entered may not have been validated for correctness. An address processor, such as a postal handling entity, may decide to validate the address to a certain degree in order to determine the correctness of the address.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
value | Indicating the quality of an address instance. | M | 1 | QualityCode |
An address is commonly linked to one or more geolocations.
The value of a location is given by EX_Extent defined
in
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
value | The geographic, temporal and vertical information of the location defined in |
M | 1 | iso19115EX_Extent |
Name | Definition |
---|---|
unstructured | The user has entered free-form text with no regard of structuring them. |
partial | Some components may be structurally correct, but some other components are still unstructured. |
full | All components are accurately separated and cannot be further split. |
Name | Definition |
---|---|
confirmedCorrect | Indicating that the address is confirmed to be correct to the best of knowledge of the address processor. |
mostlyCorrect | Indicating with high confidence that the address is correct. |
possiblyCorrect | Indicating with confidence that the address is correct. |
structurallyCorrect | Indicating that the address components have the correct value types. |
unknown | Indicating that this address has not been validated in any way, and it cannot be assigned a quality. |
The interchange layout template serves as the basis of the interchange display template and the interchange form template.
A layout template is designed to present an interchange address instance in the case of a display template, or present an input form for entry of an interchange address instance in the case of an interchange form template.
The interchange layout template is based on the following assumptions:
the resulting layout is displayed in a bounded rectangular area
the entire template is in the same script and locale.
The action of inserting components from a given interchange address instance into a layout template is called “render”.
A postal mail label can be conceptually considered as an interchange address instance rendered according to a layout template.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
id | Unique identifier for the layout template. | M | 1 | CharacterString |
name | Descriptive name of the layout template. | M | 1 | CharacterString |
description | Textual description of the layout template. | M | 1 | CharacterString |
localization | Locale and script information of the layout template. | M | 1 | Localization |
dimension | Physical dimensions of the rectangular bounding box for the rendered layout output. | O | N | LayoutDimension |
orientation | Horizontal or vertical of the text orientation. | O | 1 | LayoutOrientation |
lines | The constituent parts of this LayoutTemplate. | O | N | LayoutLine |
Physical dimensions of the rectangular bounding box for the rendered layout output.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
width | The horizontal length of the rectangular bounding box for the rendered layout output. | O | 1 | Integer |
height | The vertical length of the rectangular bounding box for the rendered layout output. | O | 1 | Integer |
The enumeration value to indicate the orientation of the address rendered by the LayoutTemplate.
Name | Definition |
---|---|
horizontal | Indicating that the address will be rendered from left to right or right to left. |
vertical | Indicating that the address will be rendered from top to bottom or bottom to top. |
A layout line represents a line in a rendered address display or an address input form.
It forms the basis of the address display line and address form line.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
dimensions | Physical dimensions of the rectangular bounding box for the rendered Line. | M | 1 | LayoutDimension |
The display template is used for displaying an interchange address instance belonging to an interchange address class. Generally, one address class is represented by one display template.
A display line represents a line within a display layout.
This represents an element within a display line.
Representing a variable data value that is contained in the interchange address component, such as the PO box number following the phrase “PO Box”.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
value | Representing a variable data value that is contained in the interchange address component, such as the PO box number following the phrase “PO Box”. This element indicates that a form field is required, and the data values accepted shall adhere to the data value type defined in its associated interchange address component (through FormLine). | M | 1 | CharacterString |
Representing static text, such as the phrase “PO Box” preceding the actual PO box number, for display layouts for PO boxes.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
text | The actual value of the TextElement. | M | 1 | CharacterString |
This section shows how an input form can be rendered according to the interchange address class.
The form template should use should also provide an example for display purposes in input (e.g., Help section).
The form template is used for displaying an input form for entry of address data into an interchange address instance. Generally, one address class is represented by one input template.
This part has no equivalence in PATDL.
A form line represents a line within a form layout.
It extends from the LineElementReference model, and takes a set of elements that contain form line element references (FormLineElementReference).
This represents an element within a form line.
In an empty form with fields generated from data elements, if the example values of the associated interchange address component are specified, such values should be used as placeholders for form input.
Representing a key value pair of a selection, e.g. in the case of the US States, “Rhode Island” is represented as the displayAs attribute and the postal code “RI” is represented as the key attribute.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
key | The mapping key as a unique identifier of the key value pair of this SelectionPair. | M | 1 | CharacterString |
displayAs | The display value of the key value pair of this SelectionPair. | M | 1 | CharacterString |
Representing a selectable mapping between display string to code, e.g. in the case of the US States, “Rhode Island” the state name is mapped to the “RI” postal code. Represented by SelectionElement and within SelectionPair.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
map | Mapping between a display string to code for each instance of SelectionPair. | M | N | SelectionPair |
Representing a variable data value that is contained in the interchange address component, such as the PO box number following the phrase “PO Box”.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
value | Representing a variable data value that is contained in the interchange address component, such as the PO box number following the phrase “PO Box”. This element indicates that a form field is required, and the data values accepted shall adhere to the data value type defined in its associated interchange address component (through FormLine). | M | 1 | CharacterString |
Static text that can be a constituent part of an ProfileCompliantAddress that complies with an InterchangeAddressClassProfile.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
value | Representing static text, such as the phrase “PO Box” preceding the actual PO box number, for form layouts for PO boxes. This element is meant to be shown in the form but not allow modification. | M | 1 | CharacterString |
DataElementWithConditions extends from DataElement to represent DataElement with additional constraints.
Name | Definition | Mandatory/ Optional/ Conditional | Max Occur | Data Type |
---|---|---|---|---|
value | The constraint information of MD_Constraint as defined in |
M | 1 | iso19115MD_Constraints |
The abstract test suites for the conformance classes defined by this part of ISO 19160-6 are presented in
Refer to
Test purpose | Check that the model contains the associations as specified. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | Check that the model contains the associations as specified. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | Check that the model contains the associations as specified. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | Check that the model contains the associations as specified. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | Check that the model contains the associations as specified. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | Check that the model contains the associations as specified. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | For each instance in the class, check that the instance appropriately includes the mandatory, optional and conditional attributes. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | For each class and type in the model, check that the model appropriately includes the mandatory, optional and conditional attributes. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
Test purpose | For each class and type in the model, check that the model appropriately includes the mandatory, optional and conditional attributes. |
Test method | Inspect the model |
Reference |
|
Test type | Basic |
An authority, such as the local post office, could “verify” a structured address that it is confirmed that this address instance is a “deliverable address” through an AddressFeature.
The owner of the address, such as the tenant of an office, could provide its signed, structured address on an electronic business card. This allows the recipient of the business card to know whether the senders address is authentic. If this address is verified to be a “deliverable address”, the recipient will know that items sent to this address will very likely be deliverable.
Extra steps need to be taken here to allow this.
Addresses do not only specify a location, in some cases they are part of the identity. For example, in business cards, an address can mean more than just an address, such as with vanity value.
This document shall support this functionality for it to be useful in contact exchange.
This address represents a complete textual address instance.
Suite 1109, Floor 11, Central Building, 1-3 Pedder Street, Central, Central & Western District, Hong Kong Island, Hong Kong
And this address represents the identical address as above, with a reduction of information that is already implied, which that does not reduce its correctness. This can be achieved by supplying a displayTemplate in the interchange address.
Suite 1109, 1 Pedder Street, Central, Hong Kong
In certain cases, an address is expected to be reachable either by person and/or post.
An address instance should support being used in conjunction with routing information, acting as a waypoint, and/or supporting a source-defined route.
Written instructions on how to deliver to a place can be unambiguous, but terribly difficult to locate. For instance, some buildings have split floors — rooms may have the same floor identifier, but is actually inaccessible from the same floor.
Models specified in this document can be represented in various
object structures, including in XML
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.