[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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?