RE: [regrep-cc-review] Slot values' order

NOW I remembered to change the subject before hitting send.

For all the 3 quotes bellow, order does not matter iff you
can fit it in 1 Slot value. I believe a SecondaryRepresentationTerm
longer than 128 is already "too long" although somebody might need
them to be this long (there were some very long string catenations
while modelling here), but PossibleValue might be an enumeration or
a regular expression, for instance, and then the length limit (not
the order itself, or lack of order) might complicate things.

Diego

> <Quote1>
> For instance, lets take a look at CoreComponentType and its fields:
> - PrimaryRepresentationTerm 1..1
> - SecondaryRepresentationTerm 0..*
> </Quote1>
> 
> Would order really matter for SecondaryRepresentationTerm?
> 
> <Quote2>
> - ContentComponent 1..1
> - SupplementaryComponent 1..*
> </Quote2>
> 
> Same for SupplementaryComponent. The UBL and UN/CEFACT ATG work is
> instantiating Supplementary Components as XML attributes (see 
> example in
> Primer above), in which case order cannot be preserved anyway.
> 
> <Quote3>
> And SupplementaryComponent has 4 fields:
> - Name 1..1
> - Definition 1..1
> - PrimitiveType 1..1
> - PossibleValue 0..*
> </Quote3>
> 
> Same for PossibleValue - does order really matter here?