RE: [ubl-ndrsc] Position Paper: Modeling Roles in UBL revision 3

[Matthew Gertner <matthew.gertner@schemantix.com>]

Eve,

I really like this idea and would respond as follows to your questions:

> - Should types that are functionally abstract (i.e., are never used
>    directly in assigning a type to a native UBL element) be declared
>    literally abstract, so that extension designers couldn't use them
>    directly themselves without further work?

Yes, unless I misunderstand the question. This would eliminate the risk that
people would use the abstract type directly, and would serve a useful
documentation purpose by identifying the type as a base for extensions
rather than as a type to be used in its own right.

> - What are the criteria for creating a more deeply nested type
>    hierarchy in any one case?  To what extent should structural
>    commonalities be factored into the ancestor type?

This cuts to the heart of good object-oriented design. They key here is that
the hierarchy should only branch if there are concrete differences between
the branches. For example, if OrderHeaderType, InvoiceHeaderType and
ASNHeaderType all have something in common, they could have a common base
type called HeaderType. If OrderHeaderType and ASNHeaderType have some
further similarities because they are both used by buying organizations,
there could be an additional type (derived from HeaderType) called
BuyerHeaderType which they are derived from.

That said, I would avoid making more than one abstract level if at all
possible, since I'm guessing it would confuse people not familiar with OO
concepts.

> - How should ancestor types be documented in the dictionary?  What
>    kinds of "things" are they?

Maybe one criterion for creating an ancestor type in the first place should
be that it is a "thing" that can be defined in some useful way. If there
isn't something specific you can say about HeaderType, it probably isn't a
type...

Matt