0..* cardinality is in one place in Figure 9 (EiEvent)

Locations 0..* (there may be many locations, or none if the event is for a set of VENs.)

Was something else intended? Optionality in other attributes is open to suggestions.

Bill:
The 0..* cardinality also exists in Figure 10. In general, it's not a good idea as this parent/child relationship exposes to orphans. This will create issues later with conformance and testing and interoperability requirements. We should try to address "optionality." If we want a relationship/attribute, let's have it. Otherwise, exclude it.

This needs to be part of the broader conformance discussion. In general, there seems to be no harm in 0..* within a complexType; are you suggesting nillable or something else?

Please describe specifically the conformance issues you raised.

Bill,
My comments was more in reference to to nillable, which will lead to optionality. In this case, I was referring to a cardinality where 0 (indicating none) when applied to interoperability compliance, which is looking for test cases against a set of standard specifications, may not result similar response in different implementations. One implementation may not have any attributes, the other may (cardinality allows that) and it's hard to be interoperable against such requirements. We need to make sure that such instances are well described – not a big issue. For DR, I still prefer if the locational attributes have a location (even if it's a set of VENs). Broadcast scenario may be different story.

I don't see any difference in parsing (and correctness of parsing).

In general I prefer absense to NIL.

I seem to be missing the point.

Ensure schemas match resolution