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
{{ message }}
This repository was archived by the owner on Jan 1, 2023. It is now read-only.
However, the XML Schema Specification is based on ISO-8601 which allows to replace the 'T' character with a space (strictly speaking it allows to "omit" it). Also, there's RFC-3339 which also allows the 'T' character to be replaced by space. Hence there's the misunderstood notion by some that it is acceptable to replace the 'T' character with a space.
There's no doubt that the above example value is not compliant with XML Schema. It is simply not a xsd:dateTime value. But the scenario is still seen in the wild from time to time. The argument seems to be readability, but that is a strange argument, because if the value is placed in XML (or JSON) then we are already outside the realm intended for human consumption. The right thing to do in the scenario would be to go back to the producer of the XML and ask him to change so that the value becomes compliant with XML Schema Specification. But what if he won't or can't or legacy compatibility issues dictates otherwise?
Considering this value:
(the 'T' letter has been replaced by a space).
Should the library accept such value?
In the XML Schema Specification for
xsd:dateTimeit clearly states that the 'T' letter is mandatory as a separator between the date and the time value.However, the XML Schema Specification is based on ISO-8601 which allows to replace the 'T' character with a space (strictly speaking it allows to "omit" it). Also, there's RFC-3339 which also allows the 'T' character to be replaced by space. Hence there's the misunderstood notion by some that it is acceptable to replace the 'T' character with a space.
There's no doubt that the above example value is not compliant with XML Schema. It is simply not a
xsd:dateTimevalue. But the scenario is still seen in the wild from time to time. The argument seems to be readability, but that is a strange argument, because if the value is placed in XML (or JSON) then we are already outside the realm intended for human consumption. The right thing to do in the scenario would be to go back to the producer of the XML and ask him to change so that the value becomes compliant with XML Schema Specification. But what if he won't or can't or legacy compatibility issues dictates otherwise?