DV_ENCAPSULATED.size attribute is missing

thanks, that is helpful Sebastian.

I'm still trying to look at other suggestions for XSD so I don't know if we're looking at an inevitable breaking change with the next release of XSDs.

Assuming we'd like to avoid that as much as possible, I think we can get away with this issue by

adding an optional 'size' to DV_PARSABLE,
relaxing 'size' in DV_MULTIMEDIA to optional.
and not touching DV_ENCAPSULATED.

This would keep the new schema backward compatible with the current one for this particular case. Since with 1.0.2 will always have size in DV_MULTIMEDIA, it'll always be valid based on a schema with the above changes. Since DV_PARSABLE will have optinoal size, existing dv_parsable's would also be valid. Finally, by not touching DV_ENCAPSULATED we lose some consistency between RM and XSD but keep it backward compatible.

if we put an optional 'size' to DV_ENCAPSULATED, then we have to modify DV_MULTIMEDIA and remove the existing 'size' there. Why? because otherwise we'd have two potential 'size's for DV_MULTIMEDIA, one inherited from the base (though optional), the other introduced by dv_multimedia. I think xml validators could deal with it, since their orders have to be different. the elements from the base have to come before the ones from the derived type due to use of sequence but it is still ugly.
If we leave this potential ugliness in place (assuming we can), we can still have backward compatibility (I think)

I can live with some pragmatism here. So my suggestion would be the above actions. Corrections to my suggestions are welcome.

Seref, your analysis is good, don't see signs of missing brain cells

Problem was as XML schema was deviating for a long time from RM, by only adding <size> in DV_MULTIMEDIA. Now if we want to be strict, we should have add it on abstract level like is specified in RM. But this is impossible without some tricks on XSD, as <size> was already present in DV_MULTIMEDIA.

DV_PARSABLE was (if I remeber correctly) missing from XSD for many years, and some implementers (like us) followed RM and had <size> there aswell. In some languages there is big difference between attribute (property) and function and once the abstract parent had a requirement for attribute... you could think what happened. Therefore we chose to only add it there in DV_ENCAPSULATED as a comment, and make sure appears in sibling DV_PARSABLE.

Meanwhile (in the last 9 years), because of different reasoning this attribute is removed from RM, and UML is changed and now we have more size() functions used.... but data instances (especially RM 1.0.2 conformant) might still have <size> both in DV_MULTIMEDIA and in DV_PARSABLE. So this needs to be accommodated by (part of another JIRA issue) adding <size> but make it optional.

Hopefully my explanation is now clear.

Thanks for the feedback Chunlan, I'll ping Tom about it.

Sebastian: you'll have to suffer my lack of brain cells a bit.

DV_ENCAPSULATED is an abstract type (in XSD as well), we'll never see an instance of that in XML.
It is valid for DV_MULTIMEDIA to add a new field by means of inheritance (in the XSD) so all is well there as well.

I'm failing to see why we need to worry about DV_ENCAPSULATED in this case: validation won't have an instance of it to deal with, so it cannot fail. Can you please tell me if I'm missing a failing case here?

Whether or not a ".size" is rightful for this class/type on RM level - is not the right place to discuss here.

Strictly related to the change caused by this ticket, it was only performed in Release 1.0.2 as a consequence that in that RM version the size was a property and not a function (see the PDF link above). Nowadays (RM 1.0.3, RM 1.0.4) is of course different. What we can do in XML schema for 1.0.2 is to relax the RM imposed constraint and make it optional - but at least it will validate those data-instances containing <size>.

And just as a remark, this is only about the DV_ENCAPSULATED.size - we use of course DV_MULTIMEDIA and/or DV_PARSABLE, which looks a bit different.

I agree with Seref that the Size should not be an attribute because it is a calculated value from the data. It is very useful when doing integrity checking on the data.