Thanks for the clarification. It need not be named
as "UBLContainer", but having a single generic name
versus having one container list name for *each*
1..n (let's put aside 0..n for the moment) has its
pros and cons. If that has been debated and decided,
then perhaps I missed reading that line where it says
the naming of lists should be a function of the 1..n
type name. But if not, let's hear your vocal objection...
I'm not quite decided on which is better, as one has
definition simplicity, while the latter has XPath
usage simplicity.
As for 0..n, what's the chair's decision on whether to
open up to discuss or?
Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/
On Tue, 3 Jun 2003, Eduardo Gutentag wrote:
>>What I mean is that UBLContainer is just a shorthand description of something
>>else.
>>
>>THere would never be something like:
>>
>><BuyerPartyType>
>> <UBLContainer>
>> <PartyName> <!-- 0..n --> </PartyName>
>> <PartyName> <!-- 0..n --> </PartyName>
>> </UBLContainer>
>> <UBLContainer>
>> <Address> <!-- 0..n --> </Address>
>> <Address> <!-- 0..n --> </Address>
>> <Address> <!-- 0..n --> </Address>
>> </UBLContainer>
>></BuyerPartyType>
>>
>>What you will encounter will be:
>>
>><BuyerPartyType>
>> <PartyNameList>
>> <PartyName> <!-- 0..n --> </PartyName>
>> <PartyName> <!-- 0..n --> </PartyName>
>> </PartyNameList>
>> <AddressList>
>> <Address> <!-- 0..n --> </Address>
>> <Address> <!-- 0..n --> </Address>
>> <Address> <!-- 0..n --> </Address>
>> </AddressList>
>></BuyerPartyType>
>>
>>There would be no common container to contain, would there? I never thought
>>at any time that someone was proposing UBLContainer as a real element name
>>for generic use whenever there was a need for a container. If I had I would
>>have opposed it quite vocally ;)
>>
>>(BTW, I still remain unconvinced that 0..n elements need containers, so
>>I'm using this particular example only because you used it, not because
>>I believe it's a good one...)