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

["Eve L. Maler" <eve.maler@sun.com>]

At 06:44 PM 2/25/02 +0100, Matthew Gertner wrote:
>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.

I agree with you.  This also allows them to be a different kind of "thing" 
in the dictionary (see below).

> > - 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.

I suspect we won't need or want super-nested types with tiny differences, 
but we'll have to see.  Factoring out commonalities gives such a huge 
benefit to all kinds of processing that there's an incentive to nest at 
least somewhat.

The problem is that it's always possible to create "trivial" ancestors that 
contain ever-smaller subsets of the material shared by all, and it's a 
matter of UBL design theory to figure out when the subset is useful vs. 
useless.

As an example, in SAML, there are five types of statement, defined in the 
following hierarchy:

o StatementType (abstract; contains nothing)
   . SubjectStatementType (abstract; adds a Subject element)
     - AuthenticationStatementType (adds authN-specific stuff)
     - AttributeStatementType (adds attrib-specific stuff)
     - AuthorizationDecisionStatementType (adds authZ-specific stuff)

We added StatementType and SubjectStatementType specifically as extension 
points, and each has some minimal semantics.  If we were just factoring out 
commonalities, we wouldn't have needed StatementType.

> > - 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...

This is a "soft" criterion, but I think in practice it would work much like 
Bill's notion of roles.  I bet there's always something that can be said 
about such items.  (Bill, what do you think about the potential for mapping 
abstract types to roles?...)

         Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com