OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: RE: [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
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:dill2@gefeg.com]
Sent: Thu 6/30/2005 9:24 AM
To: CRAWFORD, Mark; Tim McGrath; jon.bosak@sun.com
Cc: ubl@lists.oasis-open.org
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:MCRAWFORD@lmi.org]
Gesendet: Donnerstag, 30. Juni 2005 11:00
An: Tim McGrath; jon.bosak@sun.com
Cc: ubl@lists.oasis-open.org
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:tmcgrath@portcomm.com.au]
Sent: Wed 6/29/2005 11:09 PM
To: jon.bosak@sun.com
Cc: ubl@lists.oasis-open.org
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


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