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