It's interesting that there appear to be two conflicting tendencies here.
One is to tack additional, non-type-motivated information onto element names
(e.g. a Identifier of IdentifierType inside a Party is called
PartyIdentifier), the other is to remove type-motivated information (e.g. an
OrderHeader of OrderHeaderType is just called Header).
My two cents, which I already expressed at the face-to-face: the decision to
make type information transparent by differentiating say, OrderHeader and
InvoiceHeader, should stick. My impression (and, I admit, nothing more than
this) is that people would tend to want to have a more descriptive name than
Header anyway; this is why they want to tack non-type-determined information
onto element names. Since the different-types-have-different-tags approach
achieves this and contributes to our stated goal of clarity, it seems like a
good decision.
I am strongly against the idea of tacking the so-called object class onto a
type name just for the sake of it (the PartyIdentifierType example). To me
this leads to a significant loss of clarity, since the document reader can't
tell whether the PartyIdentifier is a normal identifier (of type
IdentifierType) or a specialized one (of type PartyIdentifierType).
However, I like Bill's idea of role for this purpose, although I think I
have a slightly different reading of what it is and how it would be used. To
me, the concept of role gives a more rigorous and formal framework to the
notion of qualifier that we have already discussed. In some cases, a
distinction between tags and types is a near necessity (e.g. the
BuyerParty/SellerParty example). In this case, it seems correct and
productive to call the Buyer and Seller prefixes roles, and to allow them
anywhere where they contribute to the goal of clarity.
Matt
>