[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-ndrsc] Containers
Tim McGrath wrote: > 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. I hope I didn't imply at any time that there was an importance hierarchy at play here... > > 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 > > -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]