AW: [ubl] Minutes of Atlantic UBL TC call 29 June 2005 - DECISION ON REUSABLE

Title: Re: [ubl] Minutes of Atlantic UBL TC call 29 June 2005 - DECISION ON REUSABLE

no. I 
respectfully disagree and assume a misunderstanding. 

 

A specific/generic approach (= Paradigm 1) was BEFORE 
KL. In the Reedwood city TBG17 meeting, you are referring to, the discussion was 
about he KL decisions (Paradigm 2). 

 

Redwood minutes defines a Paradigm 3 "After much 
discussion it was agreed that despite the validity of the KL decision the 
technical issues raised subsequently have put elements of it into doubt. The 
group were unable to resolve these doubts adequately and via consensus agreement 
the decision of KL was overturned and replaced by the following: ..."

 

In other words. the Redwood city meeting could not 
have said that the generic/specific was non-conformat with CCTS, because it 
simply did not discuss it.

 

 

  
-----Ursprüngliche Nachricht----- 

  
 
Von: CRAWFORD, 
  Mark [mailto:]
Gesendet: Donnerstag, 30. Juni 2005 
  22:49
An: Michael Dill; Tim McGrath; 
Cc: 
  
Betreff: RE: [ubl] Minutes of Atlantic UBL 
  TC call 29 June 2005 - DECISION ON REUSABLE

  

  
yes.  read the minutes from redwood 
  city where we determined that the old TBG17 approach was non conformant and we 
  could not substantiate it to the FMG.

  

  
  From: Michael Dill 
  [mailto:]
Sent: Thu 6/30/2005 9:24 AM
To: 
  CRAWFORD, Mark; Tim McGrath; 
Cc: 
  
Subject: AW: [ubl] Minutes of Atlantic UBL 
  TC call 29 June 2005 - DECISION ON REUSABLE

  

  

  
Mark,

  
> 
  concept of generic/specific has been dropped as 
  non-conformat with CCTS.

  
TBg17 has 
  chosen its profile of CCTS. IMO it has never said that generic/specific is 
  non-conformat. Are there any minutes, where 
  this is stated?

  
Michael

  
 

  
    
-----Ursprüngliche Nachricht-----
Von: CRAWFORD, Mark 
    [mailto:]
Gesendet: Donnerstag, 30. Juni 2005 
    11:00
An: Tim McGrath; 
Cc: 
    
Betreff: RE: [ubl] Minutes of Atlantic 
    UBL TC call 29 June 2005 - DECISION ON REUSABLE

    

    
Tim,

    
 

    
I have looked at your proposal, and 
    must confess that at first glance it appears to be exactly where TBG17 was 
    in their thinking last year.  However, subsequent harmonization efforts 
    following your thinking proved unworkable and the concept of 
    generic/specific has been dropped as non-conformat with CCTS.  I would 
    suggest that your problems are largely driven by the fact that there are no 
    underlying CCs to support the UBL BIE library, and I believe that if we 
    focus on identifying those CCs and with harmonizing with the TBG17 (not 
    TBG2) cc library, the UBL BIE library will become a much beter product that 
    will obviate the need for what you are proposing.

    
 

    
Mark

    

    
    From: Tim McGrath 
    [mailto:]
Sent: Wed 6/29/2005 11:09 
    PM
To: 
Cc: 
    
Subject: Re: [ubl] Minutes of Atlantic 
    UBL TC call 29 June 2005 - DECISION ON REUSABLE

    

    
I confess to be confused and disappointed that the point of 
    this
proposal seems to have been lost.

We are trying to establish 
    a scalable architecture for managing BIE
libraries.  As spreadsheets 
    are are primary modeling tool it doesn't add
any value to say it wouldn't 
    be necessary if we weren't using them.

As far as the CCTS 
    interpretation goes, I agree with Stephen that there
should be no 'core' 
    BIEs because it clashes with the concepts of CCTS.
 But it does not 
    follow there cannot be 'common' BIEs.  In fact Michael
Dill has been 
    advocating this for some time with his 're-use of BIEs'
ideas.  BIEs 
    can (and should) be re-used wherever possible.  It follows
then that 
    we can (and should) have 'common' ones.

The whole idea behind this 
    proposal was to make the library of 'common'
BIEs more manageable and 
    modular.

The CCTS approach of adding context by indicating the 
    context drivers is
not an alternative (in fact it complements this 
    idea).  It is a variant
on the idea of adding a column to the 
    spreadsheet and marking it
"procurement", "transportation" or 
    "common".  We already have the column
and it is called "Context: 
    Business Process".

What we are suggesting is that the UBL 2.0 
    spreadsheet is likely to have
well over 1000 'common' BIEs in one 
    spreadsheet.  Many of these are only
'common' to one context (eg 
    procurement). So why not split the
spreadsheet into more managable chunks 
    based on this criteria?  I don't
think this has anything to do with 
    CCTS.

The problem we now have is that over the next 5 weeks we have 
    to build
the stage 1 models for UBL 2.0 and we are moving away from 
    making
decisions about how to do this.  We need a timeframe for when 
    this issue
is to be resolved and it should be days rather than 
    weeks.

>DECISION ON REUSABLE
>
>   AGREED 
    that the proposed change is primarily for users of the
>   
    spreadsheets and would not be necessary if using a tool 
    that
>   was context-aware.
>
>   
    StephenG: Strictly speaking, there are no "common" or 
    "core"
>   BIEs; they exist only in context.  
    Furthermore, it appears that
>   this problem is addressed 
    by the CCTS mechanism for specifying
>   context and that we 
    might get the intended benefit by
>   completely 
    implementing the CCTS context code lists etc.
>
>   
    AGREED that we should check with our CCTS experts to 
    determine
>   whether the CCTS approach provides a suitable 
    solution before
>   continuing this 
    discussion.
>
> 
>
--
regards
tim 
    mcgrath
phone: +618 93352228 
postal: po box 1289   
    fremantle    western australia 6160

DOCUMENT 
    ENGINEERING: Analyzing and Designing Documents for Business Informatics and 
    Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476

---------------------------------------------------------------------
To 
    unsubscribe from this mail list, you must leave the OASIS TC 
    that
generates this mail.  You may a link to this group and all your 
    TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--------------------------------------------------------------------- 
    To unsubscribe from this mail list, you must leave the OASIS TC that 
    generates this mail. You may a link to this group and all your TCs in OASIS 
    at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
  
--------------------------------------------------------------------- 
  To unsubscribe from this mail list, you must leave the OASIS TC that generates 
  this mail. You may a link to this group and all your TCs in OASIS at: 
  https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php