UBL Naming and Design Rules SC

 View Only

RE: [ubl-ndrsc] Joint NDR/LC calls Tuesday and Wednesday

  • 1.  RE: [ubl-ndrsc] Joint NDR/LC calls Tuesday and Wednesday

    Posted 01-22-2003 07:11
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ubl-ndrsc message

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


    Subject: RE: [ubl-ndrsc] Joint NDR/LC calls Tuesday and Wednesday


    I'm not anxious to open a can of worms, but since it is apparently at
    least partially open anyway, let me briefly outline some of my concerns
    on this matter. I found out about the decision to go with global
    elements after the fact (which was purely my fault), and I had
    reservations about this immediately. There is the risk that we are
    introducing a "hack" into UBL that might serve as a bandaid for the
    short term, but which should hopefully be made irrelevant over the
    longer term as more processors and human users become schema (and, thus,
    type) aware.
    
    There aren't only the problems of element reuse that Ken points out.
    There is also a problem of perception and subsequent adoption. The
    extreme case is tag names like
    "ReceivedTransportHandlingUnitHandlingUnitReceiptLine", which would
    cause me personally to develop a negative attitude towards UBL off the
    bat. I'm not as inflamatory as Eve ;-), so I won't label this a
    "freakish nightmare", but it doesn't seem quite right either.
    
    If I understand correctly, the original decision to use global element
    names everywhere was intended to enable better reuse of global types
    that do not correspond to whole business messages, but might be required
    for standalone use. Can someone remind me why we didn't just stick with
    the decision to use global elements only for real top-level elements?
    This certainly wouldn't preclude having a separate file (and perhaps a
    separate namespace) where we could define global elements for all types
    to be used as an interim solution until processors are type-aware. The
    important point is that these global elements would NOT be used inside
    the UBL library.
    
    This might be an inappropriate question to ask at this stage of the
    game, but I do feel that problems in the prototyping phase are a clear
    sign that design principles should be, at very least, reevaluated and
    (presumably) reaffirmed, so I'll play the role of devil's advocate here.
    
    Cheers,
    Matt
    
    >