[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-ndrsc] Recursive container?
Folks:
My understanding is exactly what Eduardo just described. There should
never be a case where a list of list containers will need a container,
since according to our rules it would only ever produce a single list.
Cheers,
Arofan
-----Original Message-----
From: Eduardo Gutentag [mailto:eduardo.gutentag@sun.com]
Sent: Tuesday, June 03, 2003 9:40 AM
To: Chin Chee-Kai
Cc: UBL NDRSC
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
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_wor
kgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]