Re: [ubl-ndrsc] Containers

[Tim McGrath <tmcgrath@portcomm.com.au>]

Title:

i tend to agree with Chee-Kai.  there are too many uses of 0..n that would
make differing treatment seem inconsistent.  the one i noted was allowances
and charges for invoices.  these are 0..n, whereas for line items there are
1..n.  so we are likely to see the same problem Chee-Kair demonstrated at
the document level as well.

As with many of these 0..n occurrences, when we have allowance and/or charges,
we are likely to have several.  surely, this qualifies it for the 'list processing'
advantages?  the non-mandatory does not make these properties less important.

Chin Chee-Kai wrote:
> I think as well that it's important to give due considerations
> to decisions made about containers.  I'm just thinking aloud
> that if the Containers proposition hasn't included coverage
> on various possibile effects, it might be a little hasty to
> introduce them so quickly.  The "not very-disturbingly-
> backward-incompatible manner" may, by then, be the norm
> since many more instances will be in circulation than the
> schemas.
>
>
> An example I manage to find is:  <DespatchedTransportHandlingUnit>
> where, for convenience of readers, the schema is:
>
> <DespatchedTransportHandlingUnit>
>   <ID>...</ID>
>   <TypeCode>...</TypeCode>
>   <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
>   <ActualPackage> <!-- 0..n --> </ActualPackage>
> </DespatchedTransportHandlingUnit>
>
>
> So an instance could look like this:
> (for illustration, <UBLContainer> is used as the container's name)
>
> <DespatchedTransportHandlingUnit>
>   <ID>...</ID>
>   <TypeCode>...</TypeCode>
>   <UBLContainer>
>     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
>     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
>     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
>     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
>   </UBLContainer>
>   <ActualPackage> <!-- 0..n --> </ActualPackage>
>   <ActualPackage> <!-- 0..n --> </ActualPackage>
>   <ActualPackage> <!-- 0..n --> </ActualPackage>
>   <ActualPackage> <!-- 0..n --> </ActualPackage>
>   <ActualPackage> <!-- 0..n --> </ActualPackage>
>   <ActualPackage> <!-- 0..n --> </ActualPackage>
> </DespatchedTransportHandlingUnit>
>
> It's hardly uniform treatment of repetitions, I'd say.
>
>
> There's another example in OrderResponse where the schema
> is:
>
> <OrderResponse>
>   ...
>   <AllowanceCharge> <!-- 0..n --> </AllowanceCharge>
>   ...
>   <ReferencedOrderLine> <!-- 1..n --> </ReferencedOrderLine>
> </OrderResponse>
>
>
> Could NDR consider giving some more spin to the 0..n coverage
> (or other aspects of containership) before it's implemented?
>
> Thanks.
>
>
>
> Best Regards,
> Chin Chee-Kai
> SoftML
> Tel: +65-6820-2979
> Fax: +65-6743-7875
> Email: cheekai@SoftML.Net
> http://SoftML.Net/
>
>
>
>
>
> On Fri, 16 May 2003, Eduardo Gutentag wrote:
>
> > > I'd rather not go there at this time. IOW: we finally reached a decision
> > > about containers that is agreeable to all. Let's leave it
> > > there. It's not perfect, but it's a decision, and we can all live
> > > with it, and we can change it in the future if needed (perhaps along
> > > your line of thought) in a not very-disturbingly-backward-incompatible
> > > manner.
> > >     
> >   

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160