OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Abstract Type vs. Type Code

Mike Rawlins wrote

:I don't think keeping a type code
> in a superclass in order to keep a list of the subclass members is
something we
> want to do.  I'm sure that my experience in object modeling is limited
> to several of your members, but I've never seen it.  Has anyone else?
> personally don't think keeping a type code

Agreed, but first we need to realise that Type is being overloaded by the
Core Components team.

In the business process model there is something called Role that partners
"play" in transactions. Core Components use Type to indicate role. If they
changed the name of those places where Type is being used to identify the
Role being played the link between core components and business processes
would be much clearer.

The second way in which Type is being used is that of "qualifier". This is
intended to be used to distinguish specific subsets of a subtype which are
not distinguished within the core component definition. All qualifiers are,
in fact, names that should be applied to a set of context rules that apply
to the subset for particular industries/process/etc.

The third way in which type is being misused is to identify changes of

In all three cases Type is used to identify a subsetting role that is
affected by the context in which the parent element is being used. This is
the key reason why your statement about dropping type codes is correct. It
is a fundamental part of assembly (which assigns role names) and context
rules (which idnentify qualification and datatype restrictions.

Martin Bryan

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC