[ubl-ndrsc] RE: [ubl-cmsc] Specialization Architecture (was FW:Another item for issue track ing list.)

Bill,

 

Well, 
I do take Mette's point, deconstructed or not. She is looking at this from the 
perspective of mapping XML types into Java types, which makes the issue of 
polymorphism of very practical importance. If I understand correctly, you are 
pointing out that Paella permits polymorphism because in essence any type is 
compatible with the abstract base type. This is true, but it doesn't 
let a polymorphic processor (like a Java compiler) that knows about the 
base type do anything useful with the derived types, since the base type has no 
semantics.

 

What 
Mette is saying, I think, is that this is "chickening out" because we can 
claim to support polymorphism without doing any valuable analysis of 
what the immutable semantics of a type are. Derived types should 
share these semantics so that polymorphism becomes useful. Of course, all your 
examples are valid issues that we need to address (e.g. adding a new element in 
the middle of content model, removing a required element, etc.). They are solved 
by Paella but at the expense of sacrificing any real value provided by 
inheritance relationships.

 

This 
might turn out to be the best we can do. Nevertheless, we should be aware 
that there is a big cost to giving up useful polymorphism, and 
consider the possible alternatives seriously:

 

1) Give up on inheritance relationships 
altogether and go the TAAT route. At least we're calling it what it is (i.e. not 
derivation but a transformation).

2) 
Model base types carefully to enable the most possible flexibility. Force people 
to conform to these base types. Have the courage of our convictions! (I assume 
this is what Mette is getting at.) This is probably going to end up looking like 
xCBL (i.e. gobs of optional stuff) and has its own issues.

3) 
Think about what is wrong with XSD derivation and come up with a mechanism that 
better fits our requirements. Somehow get it blessed and integrated into 
tools.

 

I 
confess that I prefer route 3) despite the fact that it seems very 
idealistic. I would be for completely forgoing XSD derivation, designing our own 
UBL derivation mechanism linked to the CM and publishing it so that tool vendors 
can support it, if they wish. No one really supports XSD derivation properly 
anyway, so we're not giving up that much.

 

Matt

  
-----Original Message-----
From: Burcham, Bill 
  [mailto:]
Sent: Tuesday, April 16, 2002 
  6:16 PM
Cc: ''; 
  ''
Subject: [ubl-cmsc] Specialization 
  Architecture (was FW: Another item for issue track ing 
  list.)

  
Eduardo 
  wrote:

  
> 
  Bill,
> 
> at the risk of appearing to support a 
  different model, or of appearing to
> 
  be attacking Paella (which at this point I'm not ready to do, one way 
  or
> another), you forgot to 
  include possibility (d) in your message, namely
> the possibility that while the proposal 
  may satisfy (a), (b) and (c) entirely,
> 
  it has undesirable side effects (which is what I read in 
  Mette's
> undeconstructed 
  critique)
> 
> Eduardo

  
Good point 
  Eduardo.  To the extent possible , I hope we can cover (d)  
  by improving the use-cases (a) or their realization (b).  If a 
  side-effect is important I think we should make an attempt to express it in a 
  use-case (and XSLT/XSD etc.)  As for attacking the proposal, I'd say the 
  more attacks the better, provided we capture and reapply what we learn to all 
  our proposals.

Having had some more time to think about the substance 
  of Mette's original issue I'll take a 
  crack at a deconstruction:

Mette 
  wrote:
>     For example, you have a 
  type foo, which has no content, and is
>     
  abstract. Then you declare fooOne, which extends foo with 
  the
>     content (a, b, c). The you declare fooTwo, 
  which extends foo with
>     the content (d|e|f). 
  This means that you can encounter either one 
  or
>     the other of two completely different 
  content models. Since the base
>     type does not 
  declare any content, you have just told your
>     
  application that you can not be bothered telling it beforehand 
  what
>     content it should process, and that it 
  will have to expect any
>     content, be it fooOne, 
  or fooTwo, or some user defined extension
>     
  which it does not know about and may be written two years into 
  the
>     future.

  
(In 
  what follows I attempt to identify Requirements, Definitions and Design 
  Decisions on which we have consensus)

  
This description above 
  excludes the "implementation" types.  The proposal includes two 
  kinds of UBL types: abstract base types and derived (contentful) types.  
  The trick is that the contentful types (the so-called "implementation" types) 
  are expressed solely in terms of 
  abstract base types.  I'll make the drivers for this design decision 
explicit:

  
    
Requirement 1: It must be possible for a specialization 
    of a UBL type to add an element between two elements.

    
(Requirement 2): It must be possible for a specialization 
    of a UBL type to remove a required element.

  
We have demonstrated the solution to R1. 
  We need to add a use-case for R2.   Digging a little deeper, the notion of 
  "required" element as discussed in NDRSC is a bit complicated.  Expanding 
  R2:

  
    
Requirement 2: There 
    are three notions of a required element.  

    
      
Definition 2.1 Instances valid 
      w.r.t. a type containing a required element, must contain the required 
      element.  This is the straightforward notion of 
      XSD validation: simply that an instance document is either valid or not 
      with respect to the optionality specification of an element's 
      declaration.  

      
 

      
Definition 
      2.2 A derived type may not take away required elements. 
      XSD derivation enforces a "replacability" rule: a derived type must be 
      usable in place of its base type.  This means that if a 
      specialization is related to its base via XSD derivation then there is no 
      direct way of eliminating in a derived type a required element of a base 
      type.

      
 

      
Requirement 2.3 
      UBL specializations may need to take away required elements. We 
      came up with a notion of specializations "taking away required 
      elements".  In this case, R2.1 is maintained, but the specialization 
      (a brand new type) changes the optionality of the element such that 
      document instances may be valid with respect to the specialization and yet 
      the element may be missing.

      
 

      
Requirement 2.4 A 
      specialization may specialize either base UBL or a specialization of base 
      UBL.  Any specialization architecture must be recursively 
      applicable.  The purpose of this transitivity rule is to explicitly 
      make "in scope" the problem of extending an 
    extension.

  
We've also got a design decision from NDRSC that 
  should probably be stated as a requirement here:

  
    
Design Decision 0.1: UBL uses 
    XSD as the normative form specification of constraints on conformant 
    instance documents.  It follows that XSD schema validation is the 
    process by which documents are determined to be valid w.r.t. the UBL 
    specification.  

    
Design Decision 0.2: 
    Specializations of the UBL specification use XSD to specify constraints on 
    conformant instance documents (i.e. conformant w.r.t. the 
    specialilzation).  It follows that XSD schema validation is the process 
    by which documents are determined to be valid w.r.t. a specialization of the 
    UBL specification.

  
And one more from CMSC 
  a couple weeks ago:

  
    
Design Decision 0.3: 
    An XSD type is defined within a namespace.  Each namespace has a unique 
    name. XSD leaves open the possibility that two schema modules may 
    specify different definitions for a particular namespace.  For example:

    
      
in one schema 
      module, "mine.xsd", namespace "foo" contains complex type "Address" 
      having two elements in its content model; in another schema module, 
      "yours.xsd", namespace "foo" contains complex type "Address" having only 
      one element in its content model.

    
The UBL architecture 
    prohibits this sort of namespace "aliasing".  Namespaces are 
    immutable.  The UBL specification and conformant 
    specializations never redefine namespaces. In the example above, 
    schema module "yours.xsd" would have to define a new namespace for its new 
    Address type.

  
See the minutes for NDRSC and CMSC for full discussion 
  of the afforementioned design decisions.

  
The Paella 
  proposal seeks to satisfy requirements 1 and 2 without running afoul of Design 
  Decisions 0.1-0.3.  It does this by breaking what would be monolithic 
  (UBL) types into two pieces: interface and implementation.  The two 
  pieces together comprise the complete realization of the UBL "core 
  component".  But that could properly be viewed as so much philosophical 
  b.s. -- my point in laying out assumptions here is to draw the target on 
  the wall so to speak so we can agree on what we are shooting 
  at.

Mette 
  wrote:
>     This 
  approach, along with any, anyAttribute and anyType, is just 
  a
>     way of chickening out of adding any useful 
  content. For the sake of
>     useful application 
  processing, as much as possible should be in a
>     
  base content model, and extensions may be added later on, but 
  then
>     the extension write will have to be aware 
  that both sender and
>     reciever will have to be 
  aware of the content, and that it is done
>     on a 
  voluntary basis.

  
I'd like some examples 
  of useful application processing that is not possible in the Paella 
  model.  I've shown 7 classes of useful application processing that are 
  possible with the model.  They are labeled (see xpaths.txt and 
  use-cases.xsl):

  
    
Inheritance Selection -- 
    select in a base or specialized instance document, content of an element 
    defined in the base (and inherited in the specializations) 
    
Extension Selection -- 
    select in a specialized instance document, content of an element added 
    to the base 
    
Polymorphic Selection -- 
    select in a base or specialized instance document, an element 
    defined in the base and specialized in various ways. 
    
Tunneling Reuse Selection 
    (forgive me:) -- see xpaths.txt 
    
Global Polymorphic Selection 
    -- see xpaths.txt 
    
Global Extension 
    Selection -- ditto 
    
Selection on Type -- 
    ditto

  
I believe that 
  Mette's a|b|c extended with d|e|f example is adequately captured by case 2: 
  Extension Selection.

  
 

  
I believe Mette's comments 
  regarding polymorphism echo a widespread aversion to the whole abstract base 
  types approach (as exemplified in Paella) because on the surface it seems 
  to leave the specification too open.  We had some discussion of this in 
  CMSC and it went something like this:

  
 

  
What about this candidate 
  requirement:

  
    
*Candidate Requirement 3. 
    It should be possible to enforce in a specialization that document instances 
    conformant to the specialization use a particular specialization of a type 
    T.  For example, we'd like to enforce that specialization namespace 
    "my-UBL" define a new address type and that document instances conforming to 
    my-UBL must use the new Address definition -- never the one in "base" 
    UBL.

  
There are three 
  possible approaches to this: 

  
    
the specialization 
    defines a new schema module that imports the UBL namespace.  In a new 
    namespace, a new version of type T is defined. 
    
the specialization 
    defines a new namespace and copies all the UBL definitions into it (cut 
    & paste!), but alters the definition for type T 
    
the specialization 
    uses the "redefine" import variant to accomplish the same thing as (2) but 
    more succinctly

  
Approaches (2) and (3) violate Design Decision 
  0.3.  

  
 

  
Approach (1) fails to 
  meet Candidate Requirement 3 since a conformant instance document may contain 
  either the T defined in the UBL namespace, or the T defined in the specialized 
  namespace.  XSD type substitutability cannot be subverted.  
  Candidate Requirement 3 attempts to foreclose on XSD type 
  substitutability.

  
 

  
So AFAIK there is no 
  solution to Candidate Requirement 3 that also satisfies the other requirements 
  and design decisions.  As a result Paella does not satisfy candidate 
  requirement 3.  By far the more common case in practice is (the opposite 
  of Candidate Requirement 3):

  
    
Requirement 4: 
    Type substitutability: It must be possible 
    (convenient) to define types derived from existing types.  Derived 
    types must be usable anywhere base types are usable.  This is an 
    outcome of the decision to use XSD.

  
It should be clear by 
  now that I view the specialization architecture as independent of the context 
  methodology.  Not only is it valuable to be able to specify 
  specializations in XSD -- it is actually an outcome of the decision to "use" 
  XSD as our normative form specification language (Design Decisions 0.1, 
  0.2).  The specialization architecture is a platform upon which context 
  methodology may be applied.

  
 

  
Now there's a broad 
  target.  Fire at will!

  
 

  
Regards,

  
Bill