[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Bad Design? An XML Schema that forces applications to maintain state
- From: Roger L Costello <costello@mitre.org>
- To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Mon, 6 Feb 2023 18:47:09 +0000
Hi Folks,
I am working with an XML Schema that specifies the structure of XML-formatted messages. The messages contain data about a military battle. A battle may be just started, in progress, or finished.
The XML Schema has an element declaration that specifies the battlefield status:
<xs:element name="BattlefieldStatusCode" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="AT START"/>
<xs:enumeration value="IN PROGRESS"/>
<xs:enumeration value="FINISHED"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
The <BattlefieldStatusCode> element is optional (minOccurs="0").
The documentation says that when the first message is sent, the XML document must contain the <BattlefieldStatusCode> element; e.g., the first message contains this:
<BattlefieldStatusCode>IN PROGRESS</BattlefieldStatusCode>
The documentation goes on to say that subsequent messages may omit the element if its value is unchanged.
Eek!
Think about the implications of that for an application processing the XML messages. When the application receives the first message, the application must remember the value of <BattlefieldStatusCode>. When the next message arrives, if the message has no <BattlefieldStatusCode> element, then the application knows the battlefield status because that status value was previously stored.
In other words, the XML Schema forces applications to maintain state.
Isn't that really, really bad?
Imagine trying to map this battlefield message data format to some other battlefield data format. You would have to do state-dependent mapping. Ugh! That's awful! Right?
/Roger
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]