RE: Abstract Type vs. Type Code

["Hayes, Brian" <Brian.Hayes@Commerceone.com>]

With schema's, we acutally don't need a party type code as suggested in
William's example.

I can define SellingParty as of type Party in the a schema or as an
extension of Party (this is supported, for example, by SOX).  When a parser
sees SellingParty it will know, based on the schema _and_ the associated
semantic definition, that SellingParty is a the seller's party information.
Furthermore, if there is a Party structure inside the a Seller element, then
I can interpret the Seller:Party (or in XPATH terms, Seller/Party) as the
seller's party information (providing, of course, the associated semantic
definition of Seller:Party is the seller's party information).


Brian/

-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: Saturday, March 17, 2001 8:54 AM
To: ebXML Core
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"



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org