[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Abstract Type vs. Type Code
Mike Rawlins, Lisa Shreve and Martin Bryan are having a go-around on the EDIFACT 1131/3055 pair being simulated in code.details. I'm having a hard time understanding what's going on - though it's possible they're all talking past one another. If a hunk of data is being carried along in Party saying that this is a "Selling Party," then it stands to reason that you don't need a separate "SellingParty" schema type derived from Party. In this case - Mike's first example when he initially brought this up at the start of the thread - the only difference between a Buyer and a Seller would be a "type" passed as an element value or attribute in the XML instance. This simulates EDI: there's only one kind of NAD (Name and Address) segment for identifying parties in UN/EDIFACT (i.e., there's no SELLERNAD or BUYERNAD or CARRIERNAD) - you depend on a two character coded qualifier (i.e., piece of data) to distinguish between Buyer, Seller and Carrier. If this is the intent of the designers of ebXML's party.details, then the spreadsheet seems to be showing it (the problems noted by Mike Conroy's excellent analysis to the contrary notwithstanding). There's nothing in the spreadsheet - and hence in Conroy's UML diagram which was derived from the spreadsheet - that tells me there's any intention whatsoever of deriving "SellerParty" or "CarrierParty" descendant concrete classes from the base Party - and what would be the point if we already have the distinguishing characteristic of a coded data value indicating Party type (or "role")? Then Lisa Shreve has to go and say "the type code.... [just keeps] a list of the subclasses of party." I don't know UML modeling, but Conroy's diagram doesn't show it as a collection of subclasses to be used in isA relationships - and the spreadsheet or accompanying documentation says nothing about that either. If the magic was hidden in the "ebXML specification for the application of XML based assembly and context rules," it eluded me completely. I would agree with Mike that "...keeping a type code in a superclass in order to keep a list of the subclass members is [not] something we want to do." Surely, the UML experts can show us how to enumerate the subclass names the proper way, and doing away with the instance data in "party.type" which simulates EDIFACT's 1131/3055 pair. William J. Kammerer FORESIGHT Corp. 4950 Blazer Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "accelerating time-to-trade"
Powered by eList eXpress LLC