ubl-ndrsc — archive

[Tim McGrath]

 MHonArc v2.4.5 -->

















ubl-ndrsc message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Re: [ubl-ndrsc] Containers




From: Tim McGrath <tmcgrath@portcomm.com.au>
To: Chin Chee-Kai <cheekai@SoftML.Net>
Date: Mon, 19 May 2003 13:38:40 +0800






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









Follow-Ups:

Re: [ubl-ndrsc] Containers
From: Eduardo Gutentag <eduardo.gutentag@sun.com>



References:

Re: [ubl-ndrsc] Containers
From: Chin Chee-Kai <cheekai@softml.net>






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]