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

MHonArc v2.5.0b2 -->

















ubl message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








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




From: "Michael Dill" <>
To: "CRAWFORD, Mark" <>,"Tim McGrath" <>,<>
Date: Thu, 30 Jun 2005 15:24:20 +0200






Title: Re: [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 








References:

RE: [ubl] Minutes of Atlantic UBL TC call 29 June 2005 - DECISION ON REUSABLE
From: "CRAWFORD, Mark" <>






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]