[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-lcsc] [Analysis Team] Re: Revised Model diagram
Unfortunately, that'll run afoul of the recent switch in the NDR. Elements are now global. That means that if you see two elements with the same tag name then you can count on them being of the same type. This rule will be enforced by schema processing and validation. -----Original Message----- From: Thome, Frank [mailto:frank.thome@sap.com] Sent: Sunday, December 08, 2002 2:46 PM To: 'Tim McGrath' Cc: ubl-lcsc@lists.oasis-open.org; Michael Adcock Subject: RE: [ubl-lcsc] [Analysis Team] Re: Revised Model diagram Tim, the idea of having unambiguous items makes a lot of sense with respect to the modeling of the message structure. For the message's XML instance however we tried so far to avoid every unnecessary overhead, especially on item and on schedule line level. In so far I would suggest to realize the unambigous items only as a schema type not as a tag name, e.g. <DespatchAdvice> <Item> of type "DespatchAdviceItem" ... </DespatchAdvice> <ReceiptAdvice> <Item> of type "ReceiptAdviceItem" ... </ReceiptAdvice> The semantical relationship between the item and the corresponding "parent element" in the XML instance can already be identified by the hierarchical structure (e.g. "Item" is subelement of "DespatchAdvice" etc.). Best regards, Frank >>>>>>>>>>>>>>>>>> Frank Thome, Ph.D. SCM Development, SAP Labs Phone: +1 650-320-3174 3475 Deer Creek Road Fax: +1 650-320-3769 Palo Alto, CA 94304 >-----Original Message----- >From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] >Sent: Friday, December 06, 2002 8:35 PM >To: Michael Adcock >Cc: ubl-lcsc@lists.oasis-open.org >Subject: [ubl-lcsc] [Analysis Team] Re: Revised Model diagram > > >I would like to propose a modification to the way we are dealing with >lines/items in our model. > >Please consider something like the attached diagram. It is an attempt >to reflect the dependency of properties (i.e 'items') rather than the >structure of traditional documents (ie 'lines'). > >Basically, i think we should have a set of properties about >things when >they are ordered, transported and then charged/invoiced. The >transportation properties can be refined into those dependant on the >sending (despatch) and the receiving (receipt). > >These structures then allow us to unambiguously reconcile >Invoiced Items >with Ordered Items, Ordered Items with Transported Items , etc... > >For example, our Despatch Advice can follow the path.... ><DespatchAdvice> > <DespatchedItem> > <OrderItem> > <Order /> > </OrderItem> > <DeliverySchedule /> > <TransportHandlingUnit /> > <Shipment /> > </DespatchedItem> ></DespatchAdvice> > >and the Receipt Advice can follow the path.... ><ReceiptAdvice> > <ReceivedItem> > <OrderItem> > <Order /> > </OrderItem> > <DespatchedItem> > <DespatchAdvice /> > </DespatchedItem> > <DeliverySchedule /> > </DespatchedItem> ></Despatch Advice> > >and the Invoice can follow the path.... ><Invoice> > <InvoiceItem> > <ReceivedItem> > <OrderItem> > <Order /> > </OrderItem> > </InvoiceItem> ><Invoice> > >Does this make sense??? > > >Michael Adcock wrote: > >>Hi! >> >>Here is the revised diagram. I believe it is now up-to-date with the >>agreed mods. Also I have modified the price area..., it seems much >>simpler but still functional. >> >>I have added in Despatch Advice, Receipt Advice and Invoice, >also their >>Lines with (as yet) incomplete information but enough to >understand the >>difference and linkages. Sue and I discussed this on the 'phone. >> >>Note also that this does not include any e-mail comments sent/received >>since 15.00hrs GMT 5 Dec, if there are any! >> >>'bye for now... >> >>Mike Adcock >>Standards & Security Unit >>APACS - Association for Payment Clearing Services >>Mercury House, Triton Court >>14 Finsbury Square >>London EC2A 1LQ >>Tel: +44 (0) 20 7711 6318 >>Fax: +44 (0) 20 7711 6299 >>e-mail: michael.adcock@apacs.org.uk >> >> >> >>********************************************************************** >>The opinions expressed are those of the individual and not >the company. >> Internet communications are not secure and therefore APACS >does not >> accept legal responsibility for the contents of this message. >> If the reader of this message is not the intended recipient, or the >>employee responsible for delivering this communication to the intended >>recipient, you are hereby notified that any disclosure, >distribution or >> copying of this communication is strictly prohibited. If you have >>received this communication in error, please notify us immediately by >> telephone to arrange for its return. Thank you. >>********************************************************************** >> >> >> > >-- >regards >tim mcgrath >fremantle western australia 6160 >phone: +618 93352228 fax: +618 93352142 > > > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC