You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently icarConsignmentType has string fields for destinationAddress and `originAddress'.
Several systems store addresses in structured fields (e.g. Address 1, Address 2, City, Post Code, Country...). There is a standard for this.
It is relatively easy to convert a structured address to a string -- but much more effort to reconstitute a structured address from a string.
In Schema.Org they get around this by having:
address: { "anyOf": [ { "string" }, { "$ref": "../types/PostalAddress.json" }
(this is a simplified approximation)
At face value, this would be a non-breaking change (to validation), but I suspect it would break implementations.
An alternative would be to extend icarConsignmentType, adding destinationPostalAddress and originPostalAddress. Not as elegant, but maybe safer.
The text was updated successfully, but these errors were encountered:
Define PostalAddress from schema.org, and add it to icarConsignment's originAddress and destinationAddress.
This uses "anyOf" to support backward compatibility for the simple string type.
Resolvesadewg#317
Currently
icarConsignmentType
has string fields fordestinationAddress
and `originAddress'.Several systems store addresses in structured fields (e.g. Address 1, Address 2, City, Post Code, Country...). There is a standard for this.
It is relatively easy to convert a structured address to a string -- but much more effort to reconstitute a structured address from a string.
In Schema.Org they get around this by having:
address: { "anyOf": [ { "string" }, { "$ref": "../types/PostalAddress.json" }
(this is a simplified approximation)
At face value, this would be a non-breaking change (to validation), but I suspect it would break implementations.
An alternative would be to extend
icarConsignmentType
, addingdestinationPostalAddress
andoriginPostalAddress
. Not as elegant, but maybe safer.The text was updated successfully, but these errors were encountered: