UBL Naming and Design Rules SC

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

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

    Posted 02-25-2002 12:47
    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