UBL Naming and Design Rules SC

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...)


Chin Chee-Kai wrote:
> Do you mean "no" to the situation:
> 
> <UBLContainer>
>     <UBLContainer>
>         <A> ... </A>
>     </UBLContainer>
>     <UBLContainer>
>         <A> ... </A>
>     </UBLContainer>
>     <UBLContainer>
>         <A> ... </A>
>     </UBLContainer>
> </UBLContainer>
> 
> This wouldn't be what I meant.  Let me try again.
> 
> Let's look at BuyerPartyType.
> Here, we have from 0p70 Reusable schema:
> 
> <BuyerPartyType>
>     <ID> <!-- 1..1 --> </ID>
>     <AccountCode> <!-- 0..1 --> </AccountCode>
>     <PartyName> <!-- 0..n --> </PartyName>
>     <Address> <!-- 0..n --> </Address>
>     <PartyTaxScheme> <!-- 0..n --> </PartyTaxScheme>
>     <BuyerContact> <!-- 0..1 --> </BuyerContact>
> </BuyerPartyType>
> 
> 
> Focusing just on PartyName and Address, we can have an instance
> having containers:
> 
> <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>
> 
> 
> So question is whether <UBLContainer> should now be applied
> over the adjoining <UBLContainer>s so that it then looks:
> 
> <BuyerPartyType>
>     <UBLContainer>
>         <UBLContainer>
>             <PartyName> <!-- 0..n --> </PartyName>
>             <PartyName> <!-- 0..n --> </PartyName>
>         </UBLContainer>
>         <UBLContainer>
>             <Address> <!-- 0..n --> </Address>
>             <Address> <!-- 0..n --> </Address>
>             <Address> <!-- 0..n --> </Address>
>         </UBLContainer>
>     </UBLContainer>
> </BuyerPartyType>
> 
> 
> There could be arguments supporting "yes" or "no" answers, but
> either way, I think it might improve clarity of container's 
> applicable depth extent by stating it explicitly (ie. whether
> it is 1-deep only, or recursively applicable).
> 
> Thanks.
> 
> 
> 
> Best Regards,
> Chin Chee-Kai
> SoftML
> Tel: +65-6820-2979
> Fax: +65-6743-7875
> Email: cheekai@SoftML.Net
> http://SoftML.Net/
> 
> 
> On Mon, 2 Jun 2003, Eduardo Gutentag wrote:
> 
> 
>>>It was actually clear the first time ;)
>>>
>>>I believe the answer is "no".
>>>
>>><UBLContainer> is a shortcut, not a real name. You won't have
>>>successsive containers of the same name or type, so it wouldn't
>>>qualify, would it?
> 
> 

-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
Sun Microsystems Inc.          |         1800 Harrison St. Oakland, CA 94612
W3C AC Rep / OASIS TAB Chair