OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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

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. 

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

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 Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC