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] UBL 2.0 submission to UN/CEFACT Core component Library


Tim,
I fully support submitting UBL 2.0 to the UN/CEFACT CCL; however, might
there be different approaches (or stages) for the different libraries
contained within UBL 2.0? For example, might we start with the Common
Library and then separately deal with the procurement and transport
libraries. I am wondering to what extent should we consider the submissions
of TBGs such as TBG1 and TBG3 which seems to constitute the collaborative
base for harmonizing UBL components with equivalent within UN/CEFACT? I can
appreciate the concept of a single submission, but is that the best
strategy?

Andy


-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] 
Sent: Wednesday, February 07, 2007 12:26 AM
To: ubl@lists.oasis-open.org
Subject: [ubl] UBL 2.0 submission to UN/CEFACT Core component Library

Now that UBL 2.0 is finalized we plan to submit the UBL 2.0 Business 
Information Entities to UN/CEFACT as part of our contribution to their 
Core Component library.

This  involves transcribing the UBL library onto the spreadsheeets 
submission forms required by the TBG17 group within UN/CEFACT.

Before we go too far down this path I would like to get a review of the 
submission by the UBL TC.  This is because the submission requires some 
interpretation of our library into CEFACT forms.  For example, I propose 
that we submit our BIEs as both candidate BIE and candidate Core 
Components.  To better understand the issues I have prepared a draft of 
the submission using only the UBL 2.0 "Address". (attached)

In this form you will note that for Candidate BIEs:
a.  I have made the context of "System Constraint" to have the value of 
"XML" - in that we are only proposing XML representations of these objects.
b. BBIEs with qualified Property Terms (such as AdditionalStreetName) 
are derived from the unqualified Basic Core Component (such as 
"StreetName").

And for Candidate Core Components:
a. No qualifiers are needed. (so not all candidate BIEs are candidate CCs)
b. I have noted the mapping of our candidates to the current CEFACT Core 
Component Identifiers (where one exists).

I welcome comments and advice (as well as volunteers to help) with this 
task.

The current plan is to have this submitted before the next CEFACT Forum 
meeting at the end of March.

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.29/673 - Release Date: 2/6/2007
5:52 PM
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.29/673 - Release Date: 2/6/2007
5:52 PM
 



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