Abstract Type vs. Type Code

[Mike Rawlins <rawlins@metronet.com>]

This is the first of a few questions that are intended to help me
understand the group's thinking before I make formal comment on the
specifications.   If any of these are old ground to you, please forgive
me and help me to get up to speed.

In reviewing several of the items in the Appendix A spread sheet there
are several that have a type code.   (BTW, is this part of the official
submission, even if not an official spec?  I don't see it on the web
page for specifications for review),

For example:  Party.Details has a Party Type. Identification.Details
which contains a code value and text.   I suspect the intended use, but
I would like verification.  If I use an OO-analysis analogy, it would be
like having a Party object with an attribute of type Seller, rather than
having a Seller concrete class that is a descendent of a Party abstract
class.

I know you are trying to stay away from syntax issues in the analysis,
but there are syntax implications that have to do with your intent.  If
we take an example XML instantiation, do you intend something like:

<PartyDetails>
...
<PartyType>
...
<CodeDetails>SE</CodeDetails>
...
<PartyType>
...
<PartyDetails>

instead of in the schemas declaring PartyDetails as a complexType, with
a Seller element being a party, and having in an instance document:

<Seller>

...
</Seller>

It seems to me that in both cases you are intending the former rather
than the latter.  Please confirm.

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