RE: [ubl-ndrsc] RE: [ubl-lcsc] Newest version of the OO-design position paper.

Title: RE: [ubl-lcsc] Newest version of the OO-design position paper.

The 
argument that we remove container elements because doing so aligns us more 
closely with the Core Components Technical Specification doesn't hold water for 
me.  Is that argument coming from the fact that the CCTS 1.8 
specification failed to explicitly model "properties".  I believe 
that shortcoming will be addressed in the 1.85 specification where basic core 
component properties are modeled, and named -- so you've got a name in the Core 
Components model that you can use as a source for your element name.  Also, 
I believe "association" properties will similarly be 
modeled.

 

It is 
these "association" properties, with the appropriate multiplicity/cardinality 
map, that map nicely onto XML "container" elements I think.

 

  
  

    
      
 

    
      
Bill 
      Burcham
Sr. Software 
      Architect, Standards and Applied 
      Technology
Sterling 
      Commerce, Inc.
469.524.2164


  
-----Original Message-----
From: Stuhec, Gunther 
  [mailto:]
Sent: Friday, August 23, 2002 9:28 
  AM
To: 'CRAWFORD, Mark'; ''; 
  ''
Subject: RE: [ubl-ndrsc] RE: 
  [ubl-lcsc] Newest version of the OO-design po sition 
  paper.

  
Hello Mark,

  
 

  
"human-readable" is very efficient for defining and building of 
  applications and interfaces. The objects in the oo-design-paper are 
  "human-readable" enough for that. But the structure is simple an fits with our 
  definitions. Because we said that all components must be reusable and the 
  structure must be align on the instructions of ebXML CCTS. And I think that a 
  "Header" or "Summary" is not a reusable and logical grouping of data. In 
  addition, we defined that the complete path-name of the assembled objects 
  will be identical to the dictionary entry name. If you have hierachy like a 
  "Order", "Header" for the collection of all header information, "Parties" for 
  the collection of all parties, "BuyerParty", "Communications" for the 
  collection of all communication facilities and "Telephone.Identfier" than the 
  dictionary entry name will become "Header Parties BuyerParty Communications 
  Telephone.Identification.Identifier". I guess, this will be completley against 
  the definition of a dictionary entry name. In oo-design-paper way, the 
  path-name will be the dictionary entry name "Order BuyerParty 
  Telephone.Identification.Identifier". I think, this is semantically clear. 
  

  
 

  
Or, 
  I am wrong?

  
 

  
Kind 
  regards,

  
 

  
    Gunther

  
 

  
-----Original Message-----
From: CRAWFORD, Mark 
  [mailto:]
Sent: Freitag, 23. August 2002 
  15:28
To: ''; 
  ''
Subject: RE: [ubl-ndrsc] RE: 
  [ubl-lcsc] Newest version of the OO-design po sition 
  paper.

  
Gunther,

  
 

  
You wrote - 
  

  
 

  
But 
  all (and really all) XML instances will be processed by applications and tools 
  only. Only the designers, developers and support peoples are reading less XML 
  instances partially. Therefore, we have to think about which kind of 
  "containers" and "groups" are necessary and efficient for applications (not 
  for humans).

  
 

  
 

  
I 
  don't think this fits with what we have identified as our core principles. To 
  wit -

  
 

  
  
  
·         
  Legibility - UBL documents should be human-readable and 
  reasonably clear

  
·         
  Simplicity - The design of UBL must be as simple as possible 
  (but no simpler).

  
 

  
Mark 

  
    
Hello Joe,

    
 

    
I 
    do not know, why we need this high-level containers like "Header, Summary, 
    Party etc.". This is a separation for humans, because all layouts of the 
    hard copies of business documents are divided in this strucute. 
    

    
 

    
Kind regards,

    
    Gunther

    
 

    
 

    
-----Original Message-----
From: CHIUSANO, Joseph 
    [mailto:]
Sent: Donnerstag, 22. August 2002 
    19:13
To: Stuhec, Gunther; 'Gregory, Arofan'; 
    ''; 
    ''
Subject: [ubl-ndrsc] RE: 
    [ubl-lcsc] Newest version of the OO-design position 
    paper.

    
Hello,

    
 

    
Regarding CCTS 
    compliance:  I don't recall anywhere in the CCTS v1.8 spec that 
    mandates the structure of XML documents in regard to Dictionary Entry Names 
    (I could have missed that detail, though).  I believe that these are 2 
    separate and distinct concepts.

    
 

    
In any event, I 
    don't believe the paper made a strong enough case for doing away with "good" 
    (in my opinion) structure principles (the container approach, as we 
    call it).  Plus, I think it makes great sense to divide such documents 
    into high-level containers such as Header, Detail (or LineItem), and 
    Summary,  I believe the arguments in the paper were weighted much too 
    heavily on tools and performance - and while always a valid concern, I don't 
    believe that in this day and age either should be a concern to this regard 
    (that is, what "harm" will a few additional containership tags do for 
    performance).  I would personally like to see a much stronger case made 
    for the proposed approach.

    
 

    
Thanks for 
    listening.

    
 

    
Joe

    
************************************************************************** 
    
  Joseph M. Chiusano 
  Logistics Management Institute 
  2000 Corporate Ridge 
  McLean, VA 22102 
  
    Email:  
  Tel: 
    571.633.7722 
************************************************************************** 
    

    
      
-----Original Message-----
From: Stuhec, Gunther 
      [mailto:]
Sent: Thursday, August 22, 2002 
      12:08 PM
To: 'Gregory, Arofan'; ''; 
      ''
Subject: RE: [ubl-lcsc] Newest 
      version of the OO-design position paper.

      
Hello Arofan,

      
 

      
XML is not a hype anymore. One of that reason is the complexity of 
      the business documents. The most of the business documents have too much 
      hierarchies. More than EDIFACT or ANSI ASC X.12 ever have. These many 
      hierarchies makes the business documents very heavy or not at all 
      processable. I know some projects, which had some big problems with the 
      many hierarchies. 

      
- It was not possible to put this documents or part of these 
      documents into the databases 

      
- It was a big effort to realize any application interface for 
      processing these documents

      
- Additionally, the effort to define a XSLT rule was much more 
      higher as for defining any mapping rules for EDIFACT and Inhouse 
      formats.

      
 

      
I guess that the instances itself do not need any containers, 
      because it is easier to define any interfaces for business objects. 
      

      
 

      
My suggestion is that we have partial object classes instead of 
      unstructured containers. This partial object classes makes the building of 
      structure much more controllable and the partial object classes are 
      reausable, too.

      
 

      
Otherwise, if we use "containers", than we need some simple rules 
      for the definition and processing in a automatic manner. One another 
      import thing is, that the names containers impacts the dictionary entry 
      name. If you use a container with the name "header", than the dictionary 
      entry name will be "order.header.id" instead of "order.id". This 
      representation is not ebXML CCTS compliant.

      
 

      
Kind regards,

      
 

      
    Gunther

      

      
-----Original Message-----
From: Gregory, Arofan 
      [mailto:]
Sent: Dienstag, 20. 
      August 2002 23:20
To: Stuhec, Gunther; 
      ''; 
      ''
Subject: RE: [ubl-lcsc] Newest 
      version of the OO-design position paper.

      
Gunther: 

      
I have a fairly basic question for you. 

      
Today, most business applications do not view XML business 
      documents as a direct serialization of the objects that they use 
      internally. Rather, the business document represents a somewhat truncated 
      version of the object hierarchy, designed for exchange between 
      applications. While I see the value of having a formal relationship 
      between the model on which the object hierarchy is based, and on which the 
      business document definitions are based, I have always thought that the 
      serialization from one to the other was a very useful level of indirection 
      - different apps may actually want to take the same object structures and 
      treat them differently, given that they generally perform different 
      functions.

      
You approach removes this level of indirection (as well as 
      all the containers, making it difficult to use for non-object-based 
      systems, a different issue) - are you sure that this is the best 
      approach?

      
What I am trying to get at here is the middle ground 
      between a strictly object-based approach, and one that will be suited for 
      use by other types of applications, while not losing the merits of what 
      you have outlined.

      
Cheers, 

      
Arofan 

      
-----Original Message----- 
From: 
      Stuhec, Gunther [mailto:] 
      
Sent: Tuesday, August 20, 2002 1:57 PM 
To: ''; 
      '' 
Subject: 
      [ubl-lcsc] Newest version of the OO-design position paper. 
      

      
Hello all, 
this is our newest 
      version of the OO-design position paper. It describes generally the 
      definition of aggregate core components as well as the aggregated business 
      information entities. 

      
In this paper all aggregates representing an object. The 
      subelements which are basic business information entities representing the 
      attributes of an objects. An the aggregates insided of an objects are 
      further objects or parts of an objects. The object itself refers to these 
      furhter objects. 

      
In addition all containers are avoided, consciously.  
      Because it is not possible to represents containers as objects with 
      attributes and influence the representation of a conclusive class diagram 
      unfavorably.  

      
Please review this document and send me your comments and 
      remarks. 

      
Kind regards, 

      
      Gunther