Open gcdev373 opened 6 years ago
So, the proposal is to just change DataComplexType to be
<xs:complexType name="DataComplexType">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="Data" type="evt:DataComplexType" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>Any other event data that does not fit into a schema element but may be useful for the purpose of audit. Use the Value attribute for simple values and ComplexValue for anything more complex</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="Name" type="xs:string" use="required" />
<xs:attribute name="Value" type="xs:string" use="optional" />
<xs:attribute name="ComplexValue" type="xs:any" use="optional" />
</xs:complexType>
Do you have any complex examples at this point?
Probably better to put any complex content in an element rather than in an attribute e.g.
<xs:complexType name="DataComplexType">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="Data" type="evt:DataComplexType" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>.........</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ComplexValue" type="xs:any" minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>For use then the value is not a simple string and the 'Value' attribute cannot be used.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="Name" type="xs:string" use="required" />
<xs:attribute name="Value" type="xs:string" use="optional" />
</xs:complexType>
May want to consider ComplexValue
being in an xs:choice
with Data
, unless we foresee branches in the Data
tree with complex values, rather than just leaves.
This structure has a Name and a Value attribute, but these are both strings. There might be situations where complex data should be recorded.
Adding an xs:any element called Value could easily provide this capability.
Though maybe the name should be ComplexValue to make it less likely that the element is used where the attribute would be better.