|
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.
2. It is painful to model choice (or all) in UML diagrams.
3. If you allow choice or all, then do you also allow groups?
(a|b|(c,d,e)|f)
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.
Of
course, I would think that implementations not tied to the UBL process can
extend the base schemas using choice or all, if need be.
Tom
Tom
Gaven> I also think
the General XSD Rules section of the Naming and Design rules
document could be split into 2 sections.
Section 1. From the perspective of the UBL
'process'
Section 2. From the perspective of implementors extending
the UBL schemas.
I agree that the document should be
split. On a related point, I posted a message just before Christmas [1]
requesting that the general algorithm used in the spreadsheet be stated in
English in the NDR document, as Eve Maler once did. Only response I saw was
from Joe Chiusano (thanks, Joe).
Tom Gaven>
[GSX8, xsd:choice element MUST NOT be used]
I
really cannot understand why UBL forbids xsd:choice. Aside from the fact
that even DTDs permit choices, there are many applications in which a
content model must reflect a choice. For example, suppose a
government form allows the user to include either a TIN or SSN for
identification purposes, or another application allows one of 4 parameters
for a search. How can we possibly create UBL-compliant XSDs that meet our
business needs with such a restriction on content models? We would be forced
to create redundant schema that differ only in such choices, an obvious
maintenance headache.
Ken Sall, SiloSmashers
[also GSA e-Gov Initiative, Integrated Acquisition Environment
PMO]
|