FpML Issues Tracker

1097: String components of Address have insufficently restrictive types

March 21, 2012

confirmed

Minor

Always

Schema

FpML 6 (Build 1)

none

Admin

mgratacos

Summary

Shared component type Address contains several elements of type xsd:string:

. streetLine . city . state . postalCode

None of these elements requires to be an unrestricted string e.g. it would be undesirable for an Address component to contain non-printing/control characters.

Element 'streetLine' has multiple occurence, suggesting that a multi-line street address should be represented as a collection of streetLine elements. This implies that the element should not contain carriage returns, so the type should be changed to xsd:normalizedString (at least).

'streetLine' could be of type xsd:token, if we are satisfied that it cannot contain leading- or trailing- whitespace, or internal sequences of multiple spaces.

'city', 'state' & 'postalCode' should all be changed to type xsd:token.

Notes:

  • mgratacos

    09/06/19 5:04 am

    AWG 2019-09-05

    • The proposed changes make sense but they would break backward compatibility.
    • Agreed to add it to the FpML 6 spreadsheet changes.

    • Leave an update

    You must be logged in to post an update.

    Report an Issue

    The FpML Issues Tracker is designed to facilitate public interaction in the standard.

    By registering you will be able to submit corrections and comments, generate reports, and view the complete issues archive for FpML.

    Report Issue