Re: Abstract Type vs. Type Code

[Mike Rawlins <rawlins@metronet.com>]

William does a very good job in describing the problem I see here, but he
falls short of a point I'm trying to make.

As a general rule, I strongly feel that what we define as core components
should be considered as, in OO terms, abstract classes.   If we then examine
the various ways to use, for example "Party" in various syntaxes to express
a "Selling Party" that may or may not have additional attributes or methods
(properties in CC terms, probably context dependent), we might have the
following:

OO (Java) - Party abstract class and SellingParty descendent concrete class

XML Schema - "Party" is defined as a complexType with all of the relevant
child elements and attributes.  We then simply declare an element
"SellingParty" as type "Party"

    <xsd:element name="SellingParty" type="Party"/>

[NOTE:  There are other syntax complexities when extending "Party", but I
don't want to make this example too complex!]

EDIFACT - A NAD segment group is used to convey "Party" with NAD01 (element
3035) having a value of "SE" for seller.

William is right in saying that if I have a type code already defined in
"Party", then why have an XML element named "SellingParty".  My point is
that this particular use of type code is inherently unique to EDI syntax.
As a syntax dependent usage it should not be part of core component
definitions.  Martin points out that there are other uses of "type code"
that he thinks are valid.  I think I understand his points, but need
examples to be sure.   This is one reason why I still feel that it is
important to provide a few example instantiations of CC's in different
syntaxes so that analysts can fully understand the principles for using CCs.




"William J. Kammerer" wrote:

> 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

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/