RE: Abstract Type vs. Type Code

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

If you have not done so, take a look at Commerce One's SOX and XDK.  Using
SOX to Java compiler, you can generate Java Bean representations of the
schema.  As one would expect, OO extensions are supported.

Brian

> -----Original Message-----
> From: John.Motley@log-net.com [mailto:John.Motley@log-net.com]
> Sent: Monday, March 19, 2001 5:01 AM
> To: rawlins@metronet.com
> Cc: ebXML Core
> Subject: Re: Abstract Type vs. Type Code
> 
> 
> 
> 
> 
> Mike,
> 
> Would the follow OOP example help?
> 
> class Party has attribute role such that you could have a 
> manufacturer's
> agent with;
> 
>      Attributes like;
>      Party.role='AGENT'
> 
>      Methods like
> 
>      Party.GetAddress( ) {Returns the party's address}
> 
> you would then have in Java the ability to create a subclass of Party
> SellingParty using;
> 
>      class SellingParty extends Party
> 
> which could have access to all methods and attributes of 
> Party plus new
> ones such that;
> 
>      Old Attribute
>      SellingParty.role='AGENT'
> 
>      Old Method
>      SellingParty.GetAddress( ) {Still returns the address}
> 
>      New Method
>      SellingParty.QuotePrice(string sellersItem)  {Returns a 
> quote price to
> sell a product in inventory as identified by the seller's 
> item or product
> ID}
> 
> Not sure the present work is 100% like this.  It would be 
> nice to see more
> delineation of methods from attributes so that process and data models
> could be more easily verified (i.e. any method should have 
> parenthesis so
> that Party.quotePrice is the attribute with the value of the 
> quoted price,
> while Party.quotePrice( ) is the method to get this price.  If such a
> convention is already in place, sorry for interrupting)
> 
> Regards,
> John Motley
> 
> LOG-NET
> 
> 
> 
> 
> 
> Mike Rawlins <rawlins@metronet.com> on 03/18/2001 11:59:19 AM
> 
> Please respond to rawlins@metronet.com
> 
> To:   ebXML Core <ebxml-core@lists.ebxml.org>
> cc:
> 
> Subject:  Re: Abstract Type vs. Type Code
> 
> 
> 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/
> 
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>