Some notes regarding the actual schema.
Thanks, DW
========================================================
1)
The use of nillable is problematic in the schema and information model.
Nillable is known to cause unresolvable interoperability issues for XML instances across platforms and releases of XML parsers;
resulting in the inability to use XML Schema based validation. Especially when combined with xsd:choice() as in these cases.
Instead the nillable statements can be replaced with a attribute on the applicable element that indicates why no content is present.
The four affected items are:
- emix:extendedPrice
- emix:marketContext
- emix:packageDiscount
- emix:envelopeContents
For extendedPrice, packageDiscount and envelopeContents an optional boolean attribute of applicable with a default value set to true.
So if empty - applicable is set to false.
For marketContext this appears to be a bug - should simply be optional instead of nillable in all four occurances.
For extendedPrice and packageDiscount the xsd:choice() will ensure a child element is present - but this can simply be empty.
Unfortunately xsd:choice does not have an option to permit one or non. The alternative would be to simply make the
three parent elements extendedPrice / packageDiscount / envelopeContents all optional too.
2)
Naming issue - warrantControlability
consider just simply warrantControl
3) Annotations - elements missing annotation description: 21
- emix:emix - emix:uid - emix:createdDateTime - emix:transactiveState - emix:terms - xcal:parameters - xcal:integer - emix:extendedPrice - emix:absolutePrice - emix:relativePrice - emix:packageDiscount - emix:currency - emix:envelopeContents - emix:supportForPrice - emix:service - emix:warrantQuality - emix:warrant - emix:warrantEnvironmental - emix:warrantSource - emix:warrantContent - emix:warrantControlability
4) Model / Design
Instead of <emix:warrantQuality> <emix:warrantEnvironmental> <emix:warrantSource> <emix:warrantContent> <emix:warrantControlability>
consider instead just <emix:warrant> repeatable with an attribute of type - and then Quality, Environment, Source, Content and Control and enumerations.
This is also more easily extended in future if you need to add additional types.
Only reason for preference for current structure is if emix:warrant could have different content models based on type - but you have finessed that already by making it parameterized values.