ubl-ndrsc — archive

[Eduardo Gutentag]

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