[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: SV: [ubl-dev] Order items - substitution items - optimization
Bryan, Thanks for the clarification. I should have gone the next step and given some examples ; -) What I'm thinking is this mechanism: <ParticipantParty role="buyer/seller/etc" name="Fred"> and then of course depending on the context you can have things like: <ParticipantParty role="buyer" name="John"> <ParticipantParty role="seller" name="Anna"> but as we see in the order case this can get more complex : <ParticipantParty role="customer" name="Jim"> <ParticipantParty role="buyer" name="John"> <ParticipantParty role="seller" name="Anna"> and then even: <ParticipantParty role="customer" name="Bryan"> <ParticipantParty role="customer" name="Jim"> <ParticipantParty role="buyer" name="John"> <ParticipantParty role="seller" name="Anna"> I've also seen where this can occur - when a seller has to act as a proxy for the buyer. <ParticipantParty role="proxybuyer" name="Anna"> <ParticipantParty role="seller" name="Anna"> What this is telling us is that - I believe - there are dynamic relations - and that in each case you want the exact same block of information about that party; address, tax codes, contact, etc - and that is the KEY here - that the information model is the same - just the role and context changes. Plus I'd REALLY like to be able to reference out to partnerID - and not even have to include the data if the participants already know each others ParticipantParty information... I guess this is all about optimizations - that obviously when you are designing the information model in UML you are not so concerned with - but make a big difference to the end-user experience in actual practice in the field. However - as we move more to context driven and process driven information design - I believe we'll see that these are apparent - because intuitively humans do this stuff - so its a case of figuring out how UML/UMM accommodates that smoothly... DW "The way to be is to do" - Confucius (551-472 B.C.) -------- Original Message -------- Subject: SV: [ubl-dev] Order items - substitution items - optimization From: "Bryan Rasmussen" <BRS@itst.dk> Date: Fri, January 19, 2007 6:00 am To: "Chin Chee-Kai" <cheekai@SoftML.Net>, "David RR Webber (XML)" <david@drrw.info>, <ubl-dev@lists.oasis-open.org> I have to go with Chee-Kai (excuse me if I'm mixing surname and forename), Buyers and Sellers are derived from the class Party if I understand the thinking correctly (I have tried to keep out of the modelling/semantics discussions because I didn't agree with much from an XML aesthetics discussion and didn't see any reason to fight against what seems foregone, the downside is that I don't know much of the arguments as to why things are as they are). It seems David is arguing that rather they are both Party instances that have a role of either Buyer or Seller. This doesn't seem right because there is a major difference between them in a business context, although not modelled in UBL 2.0 internally in the structure of a Buyer or Seller, and that difference is in which direction the money is moving. Given such a major difference, even if it is implicit, it somehow feels right to identify them by naming the structure rather than by giving a generic structure a role. (but note, this is just a feeling on my part) At any rate, because of the difference in which direction the money is moving, what optimization is possible? Surely you will still have to process them seperately. Cheers, Bryan Rasmussen -----Oprindelig meddelelse----- Fra: Chin Chee-Kai [mailto:cheekai@SoftML.Net] Sendt: 18. januar 2007 05:21 Til: David RR Webber (XML); ubl-dev@lists.oasis-open.org Emne: Re: [ubl-dev] Order items - substitution items - optimization At 01:14 PM 2007-01-17 -0700, David RR Webber \(XML\) wrote: >Folks - just reviewing this - seems like Buyer and Seller substitution >items are identical structurally (but HUGE!) - therefore it would make >more sense to just have one of them in the schema structure - >repeatable - and then a mandatory LineType of either "Buyer" / >"Seller". I'm afraid this would discard the whole point of cementing the semantics of "Buyer" with the Buyer tag and the semantics of "Seller" with the Seller tag which UBL 1.0 & 2.0 so readily provide now. Informatically, you cannot throw away, or rather optimise (to put it more nicely), the bit information of "Buyer/Seller". This means that if you have a GenericBuyerOrSeller tag, you're going to need a flag of some sort as a child of that to distinguish them apart. The decision to use either <GenereicBuyerOrSeller> <Flag>I-am-a-Buyer</Flag> ... </GenereicBuyerOrSeller> <GenereicBuyerOrSeller> <Flag>I-am-a-Seller</Flag> ... </GenereicBuyerOrSeller> OR <Buyer>...</Buyer> <Seller>...</Seller> is thrashed out within UBL, and I suppose the common wisdom coming out of UBL 1.0 & 2.0 is the latter form. Best Regards, Chin Chee-Kai SoftML Tel: +65-6820-2979 Fax: +65-6820-2979 Email: cheekai@SoftML.Net http://SoftML.Net/ --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]