Re: [ubl-ndrsc] Containers

[Eduardo Gutentag <eduardo.gutentag@sun.com>]

I'm sorry if I gave the impression that consideration was not
given to all variations.

The main problem, as I see it, is precisely consistency. I will
use your example of "HandlingUnitDespatchLine" because it's a
really good one.

One way to avoid the perceived different treatement of 0..1 and 1..n
is to have a schema like this:

<DespatchedTransportHandlingUnit>
   <ID>...</ID>
   <TypeCode>...</TypeCode>
   <UBLContainer>
     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
   </UBLContainer>
   <UBLContainer2>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
   </UBLContainer2>
</DespatchedTransportHandlingUnit>

which seems to ensure consistency. The problem with this is that you
may end up with instances like this:

<DespatchedTransportHandlingUnit>
   <ID>...</ID>
   <TypeCode>...</TypeCode>
   <UBLContainer>
     <HandlingUnitDespatchLine>foo</HandlingUnitDespatchLine>
     <HandlingUnitDespatchLine>bar</HandlingUnitDespatchLine>
   </UBLContainer>
   <UBLContainer2> <!-- NOTE: it's empty -->
   </UBLContainer2>
</DespatchedTransportHandlingUnit>

Of course, the pseudo schema above can be changed to:
<DespatchedTransportHandlingUnit>
   <ID>...</ID>
   <TypeCode>...</TypeCode>
   <UBLContainer> <!-- 1..n -->
     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
     <HandlingUnitDespatchLine> <!-- 1..n --> </HandlingUnitDespatchLine>
   </UBLContainer>
   <UBLContainer2> <!-- 0..n -->
     <ActualPackage> <!-- 0..n --> </ActualPackage>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
     <ActualPackage> <!-- 0..n --> </ActualPackage>
   </UBLContainer>
</DespatchedTransportHandlingUnit>

So now UBLcontainer2 is optional; the problem is that now the following two
instances are both valid, although they are quite different:

Instance A:
<DespatchedTransportHandlingUnit>
   <ID>...</ID>
   <TypeCode>...</TypeCode>
   <UBLContainer>
     <HandlingUnitDespatchLine>foo</HandlingUnitDespatchLine>
     <HandlingUnitDespatchLine>bar</HandlingUnitDespatchLine>
   </UBLContainer>
   <UBLContainer2> <!-- NOTE: it's empty -->
   </UBLContainer2>
</DespatchedTransportHandlingUnit>


Instance B:
<DespatchedTransportHandlingUnit>
   <ID>...</ID>
   <TypeCode>...</TypeCode>
   <UBLContainer>
     <HandlingUnitDespatchLine>foo</HandlingUnitDespatchLine>
     <HandlingUnitDespatchLine>bar</HandlingUnitDespatchLine>
   </UBLContainer>
</DespatchedTransportHandlingUnit>

This is hardly consistent. As far as I know, XSD does not have concurrent
constraints that would make Instance A above invalid, which is what one
would want...

So the question must be (or at least the question in my mind is):
if <ActualPackage> is expected to be repeated many times, is it
true that it is optional? Is it really to be expected that elements
that in some cases will be 0 in others will be 10?

In any event, at this point I would prefer for the chairs to make a
determination as to whether this issue should be reopened or not.



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

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