[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Details on the Methodology
Tom - Thank you for your responses - my feedback is inline. Cheers, -Marcel -----Mensaje original----- De: Tom Gaven [mailto:Tom.Gaven@exostar.com] Enviado el: Lun 05/01/2004 09:00 a.m. Para: 'Sall, Ken'; Tim McGrath; Tom Gaven CC: ubl-dev@lists.oasis-open.org Asunto: RE: [ubl-dev] Details on the Methodology Ken, I would guess the reason choice and all are forbidden is due to the process used. 1. It is painful to represent choice (or all) in Excel spreadsheets. MJ> Should this really be a valid-enough reason to not have the use of xs:choice?? Choice is a valid business constraint - one in which several on this list and on xml-dev discuss/use. 2. It is painful to model choice (or all) in UML diagrams. MJ> I do not know the validity of your statement but I hope that, while painful, it is still representable as W3C XSD can provide for xs:choice content model. 3. If you allow choice or all, then do you also allow groups? (a|b|(c,d,e)|f) MJ> Groups are a healthy means of 'grouping' information - i will download the UBL guidance on this to see if it is allowed but I hope that it is... Actually, it isn't that it's painful to model 'choice' or 'all', it's just painful to model 'more than one' of the 3 possibilities (sequence, choice or all)... and I guess 'sequence' was the lucky winner. MJ> Within xs:choice you can have xs:sequence so order can be maintained.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]