SPECIAL MEETING NOTICE - OAGIS 9.0 LAUNCH

I am very pleased to announce that our upcoming OAGi meeting will be a
very Special Meeting with extra attention focused on the new Release
of OAGIS 9.0.  The meeting is scheduled for Tuesday through Thursday,
May  3-5, in Gaithersburg, Maryland, and will be hosted by The
National Institute of Standards and Technology (NIST).

The entire first day, Tuesday, March 3rd, is dedicated to details on
OAGIS 9.0.  We also have many other special sessions, so please make
sure you plan to attend all three days!  The agenda, meeting location
and hotel information has been posted to the OAGi web site here:
http://www.openapplications.org/global/CurrentMeeting/currentmtg.htm

The location is approximately equal distance from the three area
airports, Reagan National, Dulles, and Baltimore Washington.  There is
more location information on our web site.

EVERYONE IS WELCOME TO ATTEND.  All OAGi corporate members attend for
free, but you do not have to be an OAGi member to attend. Individual
members and non-members pay only a $275.00 fee to cover expenses.

To register, just click on this link:
http://www.openapplications.org/global/CurrentMeeting/currentmtg.htm

I will send more updates on the meeting soon.  Please contact Michelle
Rascoe at 770-943-8364 or mrascoe@... with questions.

Thanks and I wish you all safe travels to the beautiful Washington DC
area.

Dave

David M. Connelly

CEO, Open Applications Group
email: dconnelly@...
voice:   +1 770 943 8364
mobile: +1 770 331 8636

All,

Please consider this your personal invitation to come join us at our
next OAGi meeting, Tuesday through Thursday, May 1 - 3, in
Gaithersburg, Maryland, host by The National Institute of Standards
and Technology (NIST).  If you make your air travel plans now, there
are some very good prices available.

We are still working on the Agenda and it will be published shortly.
The meeting location and hotel information has been posted to the OAGi
web site here:
http://www.openapplications.org/global/CurrentMeeting/currentmtg.htm

The location is approximately equal distance from the three area
airports, Reagan National, Dulles, and Baltimore Washington.  There is
more location information on our web site.

The OAGi Spring Meeting is generally one of our most popular meetings,
so we invite you to make your plans now.  I will be sending out the
Agenda next week, but I wanted you to be able to put this on your
calendars now.

Please remember, EVERYONE IS WELCOME.

All OAGi corporate members attend for free, but you do not have to be
an OAGi member to attend. Individual members and non-members pay only
a $275.00 fee to cover expenses. To register, just click on this link:
http://www.openapplications.org/global/CurrentMeeting/currentmtg.htm

I will send more updates on the meeting soon.  Please contact Michelle
Rascoe at 770-943-8364 or mrascoe@... with questions.

Thanks and I wish you all safe travels to the beautiful Washington DC
area.

Dave

David M. Connelly
CEO, Open Applications Group
email: dconnelly@...
voice:   +1 770 943 8364
mobile: +1 770 331 8636

----- Original Message -----

From: Robin Cover

To: OAGI Core Components Work Group

Sent: Wednesday, January 26, 2005 10:57 AM

Subject: [OAGI-CoreComponents] Alignment of ATG2, UBL, and OAGIS on NDR (?)

Garret (or anyone)...

Notices have been posted about the approval of the OASIS UBL
NDR, UN/CEFACT XML Naming and Design Rules [Step 6 of the ODP -
Implementation Verification], and DON XML Naming and Design Rules 2.0

Can someone provide an updated summary statement describing
the alignment of OAGIS (CCT Schema Module definitions and
other features) with any of these 'NDR' (draft) documents?

Anything short and sweet (one sentence) will be adequate,
but I'd like to quote it in a news item.  If anyone feels
motivated to provide a 1-2 paragraph description for public
use, that would be welcome too.

Garret Minakawa had written earlier (Sep 14, 2004) relative to
the ATG2 working group session on OAGi comments for
ATG2 NDR Draft 1.0:

<q>... these changes will now bring ATG2, UBL, and OAGIS into virtually
100% alignment for the CCT Schema Module definitions...</q>

http://groups.yahoo.com/group/OAGI-CoreComponents/message/398

Many thanks,

Robin Cover
XML Cover Pages
http://xml.coverpages.org/

robin.cover@...

Garret (or anyone)...

Notices have been posted about the approval of the OASIS UBL
NDR, UN/CEFACT XML Naming and Design Rules [Step 6 of the ODP -
Implementation Verification], and DON XML Naming and Design Rules 2.0

Can someone provide an updated summary statement describing
the alignment of OAGIS (CCT Schema Module definitions and
other features) with any of these 'NDR' (draft) documents?

Anything short and sweet (one sentence) will be adequate,
but I'd like to quote it in a news item.  If anyone feels
motivated to provide a 1-2 paragraph description for public
use, that would be welcome too.

Garret Minakawa had written earlier (Sep 14, 2004) relative to
the ATG2 working group session on OAGi comments for
ATG2 NDR Draft 1.0:

<q>... these changes will now bring ATG2, UBL, and OAGIS into virtually
100% alignment for the CCT Schema Module definitions...</q>

http://groups.yahoo.com/group/OAGI-CoreComponents/message/398

Many thanks,

Robin Cover
XML Cover Pages
http://xml.coverpages.org/

robin.cover@...

• Phase I identifies semantic matches at the ACC level (i.e. does the approved TBG17 ACC have an equivalent component in OAGIS based on the ACC name and definition)
• Phase II analyzes the properties (BCCs) of the ACC to determine the level of compatibility between TBG17 and OAGIS

• Account. Details (GL Account and Credit Card account info exist but no separate Account object)
• Range. Details
• Event. Details
• Organization. Details (Information is currently included in Party object.  No separate object for Organization)
• Country. Details (OAGIS uses a Country_ Code. Type datatype and a Country Code property term but no separate object for Country)
• Country Sub-Division. Details (OAGIS uses a Country Sub-Division_ Code. Type datatype and a Country Sub-Division Code property term but no separate object for Country Sub-Division)
• Business Profile. Details
• Complete Work. Details
• Construction Type. Details
• Contract. Details
• Document. Details
• Examination Result. Details
• Guarantee. Details
• Metrics. Details

FYI

Stig Korsgaard wrote:

> Dear all,
>
> For some time we (TBG17 management) have tried to compile some information
that could give you a reasonable overview of where TBG17 is and how we are
progressing with our workload, which seems to increase week by week.
>
> As you know we have produced most of our key documents in a version 1.0. That
includes the rules and procedures under which TBG17 work, the guidelines and
procedures for submissions and harmonization work and the templates/checklists.
>
> We have also released the first set of Core Components that although labelled
"the first 19" actually is much more while they in total contains 19 ACC´s and
186 BCC´s. We still miss the change request template to amend these, but it is
on its way.
>
> In terms of submissions we still have 9 "active" submissions meaning they have
official status and is being processed. A couple of submissions is withdrawn due
to them being outdated and superseded by new versions in their respective
domains. This is even true for others of the active ones, but as we all know
natural in a period of time where everybody both TBG17 and the (potential)
submitters has been in a learning phase, where even basic concepts has
developed. We should though be passed that now and it is expected that in our
next meeting TBG17 will address the first BIE's in addition to the CC´s. And
once they come, the new submissions will just add so much richer to the
harmonization.
>
> Let this by the way be a reminder that we still very much would like to
receive new submissions. The more the better for the final harmonized result.
>
> In terms of progressing the current submissions TBG17 editorial team have
produced a version of our CC´s in a combined spreadsheet (attached) that not
only contains the released set of CC´s but also the next draft and the related
set of CC´s, which we will worked upon in our next meeting. Note that the draft
set says draft 39, but it is correctly 38.
>  <<related versus 19 and 38.xls>>
> In addition there has also been produced a spreadsheet that shows how the
current three different set of CC´s (the released, draft and related) is divided
in relation to the submitters, meaning what part of the different submissions is
covered by the different batches of CC´s. This also shows - interpreted in
another way - what the completion rate is or will be.
>  <<20041129PercentComplete.xls>>
> Note that the percentages is estimates, but fairly close.
>
> Note also that even if TBG17 operates on the basis of processing submissions
on a "first in - first out basis", we also have the need to be efficient meaning
that similar concepts will get
> processed at the same time at the meetings.
>
> If you wonder why some of the CC´s is attributed to TBG17 it is because it is
either the harmonized result of our work or because some of the things have been
combined between submitters and raised to a TBG17 level. Finally there is also a
few of examples where we have had the need to add BCC´s  - based on submissions
but not in there as such. This in order to make ACC´s complete.
>
> All this means that we are still some time away from progressing a full
concept in terms of a message, but actually this is more due to the fact that we
have had the need to get a pretty good idea of what the CC´s are and populate
the library before we could or can go to the BIE level, which essentially is the
level that is the important one for the users. Furthermore in order to progress
a message we are still missing the document assembly part, that is missing in
CCTS and yet to be developed.
>
> On other statistics TBG17 now have 20 voting members + 2 general members and
there are still a number of potential groups missing. We also have an increased
number of requests from especially other CEFACT PG to work with them and it is
very difficult for TBG17 to use resources for that while at the same time needs
so heavily to focus on the harmonization. In essence a number of these request
are as much the responsibility of the full TBG, but more on that later.
>
> In order not to make this message to long, I will leave the report here, but
if you have any questions please contact me.
>
>
>
> Best Regards
>
> Stig Korsgaard
> TBG17 Chair
> M.Sc.E Standardisation Manager
> Tel:    +45 3370 1083
> Cell:   +45 2725 9083
> Mail:   stk@...
>
> Danish Bankers Association
> Amaliegade 7
> DK-1256 Copenhagen K
> Tel:    3370 1000
> Fax:    3393 0260
> mail@...
> www.finansraadet.dk
>
>   -----------------------------------------------------------------
>                                       Name: related versus 19 and 38.xls
>    related versus 19 and 38.xls       Type: Microsoft Excel Worksheet
(application/vnd.ms-excel)
>                                   Encoding: base64
>                                Description: related versus 19 and 38.xls
>
>                                      Name: 20041129PercentComplete.xls
>    20041129PercentComplete.xls       Type: Microsoft Excel Worksheet
(application/vnd.ms-excel)
>                                  Encoding: base64
>                               Description: 20041129PercentComplete.xls
>
>   -----------------------------------------------------------------
>
> ---
> You are currently subscribed to un-cefact-tbg17 as:
garret.minakawa@....
> To unsubscribe send a blank email to
leave-un-cefact-tbg17-52261O@...

I will work on updating the spreadsheets and UML models based on
last week's meeting, then post the results to the site.  Please
review and reply with any comments once these documents are
posted.

There is also an updated spreadsheet from TBG17 available.

garret

Posted to the Minutes folder within Files.

garret

Thanks to the NY State Attorney General, I am no longer employed at Marsh.

Please direct all future emails (for now) to my home at marstal2@....


If anyone knows someone hiring, I would appreciate any help.

Thanks,


alan

Due to F2F meeting.

Francois Vuilleumier wrote:

++ ebCCTS (core components) are now an ISO Technical Specification: results
of the ballot, see file 154n466a1 attached
++ more on ebCCTS, now ISO TS15000 part 5, goto (ID + password, see below):
http://isotc.iso.org/livelink/livelink?func=ll&objId=3233203&objAction=browse&sort=name
++ more on the 4 previous ebXML parts, also ISO TS15000 parts 1 to 4, goto
http://isotc.iso.org/livelink/livelink?func=ll&objId=3233082&objAction=browse&sort=name
++ or goto ISO/TC154 web, folders [F] 1. and [F] 2.
++ a press release should soon be issued by the UN/CEFACT Secretariat in Geneva

  ----------------------------------------
                                                 Name: 154n466a1 ebXML votes TS15000-5.pdf
   154n466a1 ebXML votes TS15000-5.pdf           Type: Acrobat File (application/pdf)
                                             Encoding: base64
                                      Download Status: Not downloaded with message

  ----------------------------------------
===
open trade data interchange is our aim
François Vuilleumier, ISO/TC154 chair + ISO7372MA secretary
http://www.iso.org/tc154 => [top right] click to login
=> user: tc154 + password: opendi
===

Garret,

my .02

1.  Indicator. Type.  Both OAGi and ATG2 have translated the CCT
Indicator. Type into the xsd:boolean built-in type.  Furthermore,
the list of valid values has been reduced to "false" or "true"
(other values allowed by xsd:boolean are "TRUE", "FALSE", "0",
"1").  The reasoning is that since each of these sets of values
does not change the semantics of what is being communicated,
there should not be multiple representations for the same
semantic concept.  The pair "true", "false" was selected because
it was felt that it best conformed to existing usage of
booleans.  It has been argued that "0", "1" would be a more
international representation since it is not language specific.
What do you think?

NOTE:  It has also been argued that Indicator. Type should be
anything with two, and only two valid values which would prevent
it from being defined as xsd:boolean.  I'd like to set aside that
argument for now and assume we are only dealing with xsd:boolean.


<AJS>"0" and "1" are certainly more international that "true" and "false"
and if we are going to restrict the standard it should be to "0" and
"1".</AJS>

2.  Identifier Lists.  The ATG2 NDR has introduced the concept of
"Identifier Lists".  Line 530 states "In those cases where
identifier schemes mimic the functionality of code lists,
reusable identifier lists schema modules will be created to
minimize the impact of identifier list changes on root and other
reusable schema.  Each reusable identifier list schema module
will contain enumeration values for codes and code values".
Should OAGIS implement Identifier Lists?  If so, what rules or
guidelines should apply in order to determine if something is an
Identifier List or not?

3.  Code vs Identifier.  I put this one last so you wouldn't
immediately delete this email.  Do we now have some general
consensus about how to distinguish codes from identifiers and
vice versa?  Has anyone taken all of the material written to date
and summarized them into a clear set of rules/guidelines?

<AJS>2 and 3 seem to go together and get into the same old discussion
between codes and identifiers.  I don't think anyone will ever agree on
what is a code and what is an identifier, so opening the discussion again
does not seem to be the right thing to do.  I have disagreed since day 1,
and have been out voted each time -- I have given up on this.  The concept
of identifier lists is just another code list/identifier discussion.  If an
identifier needs an identifier list, shouldn't it just be a code list?
This is a never ending battle :-( </AJS>


Regards,

Alan Stitzer
AVP, Mgr Global Standards
Marsh USA, Inc
253 Coconut Pt
Jupiter, FL 33458
USA

office:    561 743 1938
mobile: 561 371 5339
fax:        561 743 1993



              garret.minakawa@o
              racle.com@Interne
              t                                                          To
                                        OAGI-CoreComponents@yahoogroups.com
              11/03/04 01:53 PM         @Internet
                                                                         cc

                                                                    Subject
                                        [OAGI-CoreComponents] FEEDBACK
                                        REQUESTED: Misc CC Implementation
                                        Issues










1.  Indicator. Type.  Both OAGi and ATG2 have translated the CCT
Indicator. Type into the xsd:boolean built-in type.  Furthermore,
the list of valid values has been reduced to "false" or "true"
(other values allowed by xsd:boolean are "TRUE", "FALSE", "0",
"1").  The reasoning is that since each of these sets of values
does not change the semantics of what is being communicated,
there should not be multiple representations for the same
semantic concept.  The pair "true", "false" was selected because
it was felt that it best conformed to existing usage of
booleans.  It has been argued that "0", "1" would be a more
international representation since it is not language specific.
What do you think?

NOTE:  It has also been argued that Indicator. Type should be
anything with two, and only two valid values which would prevent
it from being defined as xsd:boolean.  I'd like to set aside that
argument for now and assume we are only dealing with xsd:boolean.

2.  Identifier Lists.  The ATG2 NDR has introduced the concept of
"Identifier Lists".  Line 530 states "In those cases where
identifier schemes mimic the functionality of code lists,
reusable identifier lists schema modules will be created to
minimize the impact of identifier list changes on root and other
reusable schema.  Each reusable identifier list schema module
will contain enumeration values for codes and code values".
Should OAGIS implement Identifier Lists?  If so, what rules or
guidelines should apply in order to determine if something is an
Identifier List or not?

3.  Code vs Identifier.  I put this one last so you wouldn't
immediately delete this email.  Do we now have some general
consensus about how to distinguish codes from identifiers and
vice versa?  Has anyone taken all of the material written to date
and summarized them into a clear set of rules/guidelines?

For example, I think there is general agreement that Codes are
"relatively" static and are "usually" maintained by some
authorized agency.  They are a shortened/encoded/abbreviated
representation of some "thing", normally text, and usually of the
same consistent length within a code list.  If we can capture
these attributes/characteristics as a set of rule, guidelines, or
some kind of checklist, I'm sure it would help a lot of people
trying to implement CCTS.

Thanks,

garret


[attachment "C.htm" deleted by Alan Stitzer/NYC-NY/US/Marsh/MMC]
[attachment "Garret.Minakawa.vcf" deleted by Alan
Stitzer/NYC-NY/US/Marsh/MMC]

Roll Call
Review Agenda for Nov 8-11 F2F Meeting
Discussion of Open Implementation Issues
Start Review of TBG17 Draft ACCs

NOTE:  It has also been argued that Indicator. Type should be anything with two, and only two valid values which would prevent it from being defined as xsd:boolean.  I'd like to set aside that argument for now and assume we are only dealing with xsd:boolean.

2.  Identifier Lists.  The ATG2 NDR has introduced the concept of "Identifier Lists".  Line 530 states "In those cases where identifier schemes mimic the functionality of code lists, reusable identifier lists schema modules will be created to minimize the impact of identifier list changes on root and other reusable schema.  Each reusable identifier list schema module will contain enumeration values for codes and code values".  Should OAGIS implement Identifier Lists?  If so, what rules or guidelines should apply in order to determine if something is an Identifier List or not?

3.  Code vs Identifier.  I put this one last so you wouldn't immediately delete this email.  Do we now have some general consensus about how to distinguish codes from identifiers and vice versa?  Has anyone taken all of the material written to date and summarized them into a clear set of rules/guidelines?

For example, I think there is general agreement that Codes are "relatively" static and are "usually" maintained by some authorized agency.  They are a shortened/encoded/abbreviated representation of some "thing", normally text, and usually of the same consistent length within a code list.  If we can capture these attributes/characteristics as a set of rule, guidelines, or some kind of checklist, I'm sure it would help a lot of people trying to implement CCTS.

Thanks,

garret
 

Mike Rowell, OAGi Chief Architect, will be presenting the new
implementation of Code Lists and Enumerations for OAGIS 9.0.

If extra time is available, we will review the recently published
list of candidate ACCs from TBG17.

garret