Investigate when message validation is done

[criadoperez]

Validate the ERN4.3 schema is correct using the xsd file.

There is an expected order and the XML won't validate against the schema if the <List> elements are not in the right order.

When validating the XML file, we need to check which elements are restricted to a specific sequence by the presence of the <xs:sequence> tag on the Parent element in the XSD file. I.e. if a <xs:sequence>tag is present on the Parent element then all children must be in the order given in the XSD file

Validate the signature

Validate the sender is part of the DP whitelist

Validate the specified record's unique 'key fields' are being are being declared

[revelator-labs]

@denciu - Please note this update from the Revelator Distro team:

There is an expected order and the XML won't validate against the schema if the elements are not in the right order. You can check which elements are restricted to a specific sequence by the presence of the tag on the Parent element in the XSD file. I.e. if a tag is present on the Parent element then all children must be in the order given in the XSD file

[revelator-labs]

@criadoperez / @denciu based on the above, I've added to the description of this task the need to validate the List elements are in order;

I assume from this that all other elements do not need any specific order; @criadoperez feel free to inquire further on Slack if you feel we need any further information

[denciu]

@criadoperez @revelator-labs Unfortunately this tells us nothing more than what is in XSD spec and we are aware of it. It means that if we got piece of schema like this:

 <xs:element name="NewReleaseMessage">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="MessageHeader" type="ern:MessageHeader">

                </xs:element>
                <xs:element name="ReleaseAdmin" minOccurs="0" maxOccurs="unbounded" type="ern:ReleaseAdmin">

                </xs:element>
                <xs:element name="PartyList" type="ern:PartyList">
                </xs:element>
            </xs:sequence>
         </xs:complexType>
 </xs:element>

this message would be invalid:

<NewReleaseMessage>
   <PartyList>
      ...
   </PartyList>
   <MessageHeader>
      ...
   </MessageHeader>
</NewReleaseMessage>

because PartyList occurs before MessageHeader.

To make story short - sequence validation is formality. Imagine that we ignore ordering for a while. If we receive <PartyList> and then <MessageHeader> or <MessageHeader> and then <PartyList> it doesn't matter because they are inside <NewReleaseMessage> and are present (schema states that they are required). After parsing we can access these properties like NewReleaseMessage.PartyList or NewReleaseMessage.MessageHeader. Ordering is just irrelevant formatting, improving human readability.

Common XML Parsers have sequence validation out of the box but unfortunately they don't work with Risc0.

XML parser that I'm working on doesn't validate sequences yet. It is possible to implement but it will take me really long time. But before even thinking about it let's consider do we really need it. If message content is correct but in wrong order, our software parses it and understands it do we really need it? It would be only for formality.

[criadoperez]

Thanks @denciu I'm more inclined to not enforce the order of the fields in our schema, but getting confirmation from other parties if its also ok for them.

[revelator-labs]

I agree it makes more sense to ignore this order; We do not care about the order in which to present assets in a release. This or similar issues may be critical for DSPs but our parser can ignore it indeed @denciu

[criadoperez]

Closing this issue as completed as order is not longer an issue for us and we wont enforce it.