EMIX v1.0 Public Comment Review feedback

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.