Re: [ubl] new work item for UBL

["Stephen Green" <stephen_green@seventhproject.co.uk>]

Thanks Michael

I imagine that trying to add ACCs in time
for the next release would at least put back
the release date by a long way. Unless a
lot of work has already been completed.

I do wonder about the feasibility. I do agree
though that this should be on the issues list for
2.0 at least.

Are there any other areas where there should
be closer compliance to CCTS. I remember
it was mentioned by Mark that we might be
amiss regarding the qualifying of ABIEs
I think. I reckon that should be an issue list
item too.

All the best

Steve


----- Original Message ----- 
From: "Michael Dill" <dill2@gefeg.com>
To: "Stephen Green" <stephen_green@seventhproject.co.uk>; "Ubl"
<ubl@lists.oasis-open.org>
Sent: Wednesday, May 18, 2005 3:17 PM
Subject: AW: [ubl] new work item for UBL


> Stephen,
> 1. yes,
> 2. UBL is not compliant, at least bceause of the complete absence of ACC
>
> Originally there was a schedule to incorporate minor changes only. Under
> this assumption it would not have been so important to amend the UBL
> architecture.
> Now I expect a greater number of messages and see a major version. Clear,
> that then I'd like to see UBL ISO 15000-5 compilant.
> regards
> michael
>
> -----Ursprüngliche Nachricht-----
> Von: Stephen Green [mailto:stephen_green@seventhproject.co.uk]
> Gesendet: Mittwoch, 18. Mai 2005 13:46
> An: Ubl
> Betreff: Re: [ubl] new work item for UBL
>
>
> Michael
>
> Greetings
>
> Two things:
> 1. I think the issue you are raising here is about CCTS
> compliance or otherwise. Is that right?
>
> 2. Please would you clarify specifically the non-compliant
> aspect as you see it. The reason I ask is not just to increase
> CCTS compliance but (to me more important) because
> I'm hoping that improving compliance might actually
> improve the UBL architecture and solve some of the
> potential problems I forsee needing solutions in UBL 2.0.
> I'm all for improving compliance with CCTS as long as it
> actually helps UBL solve the challenges it faces. I guess
> I'm suggesting UBL looks more closely at CCTS now
> to see if this is so. Anything to help UBL do this would be
> especially valuable to UBL right now (in my opinion).
>
> All the best
>
> Stephen Green
>
>
> ----- Original Message -----
> From: "Michael Dill" <dill2@gefeg.com>
> To: "Stephen Green" <stephen_green@seventhproject.co.uk>; "Ubl"
> <ubl@lists.oasis-open.org>
> Sent: Wednesday, May 18, 2005 12:03 PM
> Subject: [ubl] new work item for UBL
>
>
> > Thanks Stephen and dear all,
> >
> > oh, then we do have a new work item to discuss:
> > 1. Is UBL compliant with ISO15000-5 CCTS and ISO 11179 or not?
> > 2. Is this compliance considered to be important by the TC?
> >
> > As you know GEFEG is the vendor of the e-bla-bla development and
> > documentation tool GEFEG EDIFIX. As far as I know we are the only XML,
> > Modelling and EDI tool manufacturer, which did not yet give up to
support
> > the UBL schema generation - despite (as TIM MCGRATH himself said to me)
> > having achieved the necessary level of frustration with the way the UBL
TC
> > works. Yes, GEFEG is frustrated and yes, the UBL NDR are not so good as
> the
> > ATG2 one (independent from the global - local issue). But they were good
> > enough for a starting point. And - this is important for me - UBL
started
> > and continued to do an excellent job, whilst CEFACT just continued to
> > discuss any (im)portant issues.
> >
> > Gunther Stuhec gave up to write scripts for UBL schema generation over
> > issues like these and with him went the whole SAP ERP and SAP markets,
> with
> > the result that, UBL Schemas will probably never became the native XML
> > standard of SAP. OK, we might say, SAP is not the world, they just have
> 67%
> > market share in Europe and 20 points less in US. But just NOW we have to
> > realize that the OAGI standard 9.0 has recently implemented ALL the ACCs
> of
> > UN/CEFACT/TBG17.
> >
> > Chai-Kai lost heart as well and there was never any officially raised
> > questions as to why these guys (Gunter from SAP, and Chai-Kai) stopped
> their
> > support for UBL schema generation. There wasn't any recorded discussion
> > about what lessons should be learned, why they did give up to do it etc.
> We,
> > i.e. the UBL TC need more than one tool in order to achieve a high
quality
> > of data, at least this is, what I believe.
> >
> > As the vendor of EDIFIX, GEFEG naturally tries to implement whatever a
> user
> > would require. As a vendor we cannot afford to have a particular
opinion.
> > Thus you can trust that David Kruppke and I will do our very best to
> > implement the UBL NDR. The GEFEG EDIFIX tool handles UML, XML, EDI and
> > within these mappings etc. It also manages UBL, RNet, GS1, EDI, X12,
OAGI
> > etc.
> >
> > But I can, and do, have a personal opinion. I believe in standards and I
> > will vote AGAINST any next UBL version, which claims to be CCTS
compliant
> > and which is, in fact, not. And I would explain my pros and cons to the
> > whole UBL TC before any balloting which I would hope would encourage the
> > non-speaking majority of UBL members to express their expectations and
> > hopes.
> >
> > As long as I am allowed to be the German Hood for ISO, I can never vote
> that
> > a NON-CCTS compliant UBL standard becomes an ISO Standard. BUT very much
> > welcome are any comments for the update and preparation of the next CCTS
> > version 2.x. What can I expect here in the next weeks from the UBL TC?
> >
> > Anyway, hereby I ask to add this issue to the action list, which should
be
> > solved before the next release of UBL.
> > regards,
> > Michael Dill
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Stephen Green [mailto:stephen_green@seventhproject.co.uk]
> > Gesendet: Dienstag, 17. Mai 2005 19:16
> > An: Ubl
> > Betreff: Re: [ubl] ACC? AW: [ubl] PLENARY REPORT FROM THE UBL TC MEETING
> > IN HANGZHOU 9 MAY - 13 MAY 2005
> >
> >
> > Folks
> >
> > > > This will resolve the current inconsistency issue raised by NDR
where
> > > > we
> > > have some BBIEs in documents and not in the Common Basic Components.
> >
> > Just noting that the original issue seems
> > not to be whether a document has BBIEs
> > just below the top level but whether these
> > BBIEs belong to the document namespace
> > or to the common or core namespaces
> > (common basic components).
> > In other words if they belonged to the
> > document namespace then they would be
> > "not in the Common Basic Components".
> > This is the UBL 1.0 problem I think is to
> > be addressed.
> >
> > All the best
> >
> > Steve
> >
> >
> >
> > ----- Original Message -----
> > From: "Michael Dill" <dill2@gefeg.com>
> > To: "Catherine Williams" <catherine.williams@pisces.co.uk>; "Tim
McGrath"
> > <tmcgrath@portcomm.com.au>
> > Cc: "Ubl" <ubl@lists.oasis-open.org>
> > Sent: Tuesday, May 17, 2005 5:38 PM
> > Subject: [ubl] ACC? AW: [ubl] PLENARY REPORT FROM THE UBL TC MEETING IN
> > HANGZHOU 9 MAY - 13 MAY 2005
> >
> >
> > > Catherine,
> > > Oh, no! I'm not suggesting that you create your own ACC for every
> > document.
> > > They should be provided by the standard library.
> > > imo CCTS as a semantic driven data modeling methodology has a specific
> > > inheritance between ACC and ABIE.
> > > If UBL has defined ACCs as required by CCTS, I guess that you would
not
> to
> > > have to build an ACC in > 95% of all cases.
> > >
> > > Among others - the promise of a standard is to guarantee a consistent
> > > development methodology and consistent data. To achieve the latter, it
> is
> > > necessary to reuse objects instead of retyping, and to avoid any data
> > > redundancy.
> > >
> > > As long as users have just a few documents, which are rather more
static
> > > than dynamic (in respect of the number of necessary changes per year),
> > they
> > > do not yet care so much about it. Thus I do not yet expect, that
those,
> > > which implement the invoice only, are necessarily looking for this
> > already.
> > > But the more documents and the more real life changes these documents
> > have,
> > > the more attention pay users to these aspects in order to decrease the
> > > maintenance costs of the eRelationships and to make their own
documents
> > > interoperable. For example, if the Chinese Committee is going to
develop
> > 60
> > > highly inter-related documents, then these aspects become very
important
> > > from the very beginning.
> > >
> > > The second issue, which I feel is important with these ACC artifacts,
> is,
> > > that they are part of a concept how users extend/customize UBL
standard
> > > document. They, but not only they, rule, what a user can do in
> customizing
> > > and extending UBL. I do not believe, that all users agree to give all
> > their
> > > data to a published standard. This is valid in US, but even more in
the
> > non
> > > Anglo-Saxonian world. This is the lesson, I've learned from so many
> > private
> > > extensions of RosettaNet, EDIFACT etc. and we should take this into
> > account.
> > > Thus, the ACC and the concept, how to use them for and by UBL users,
> > should
> > > play an important role in order to help users to make their
developments
> > > aligned with the Standard and in the end more interoperable.
> > >
> > >
> > > Regards,
> > > Michael
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Catherine Williams [mailto:catherine.williams@pisces.co.uk]
> > > Gesendet: Dienstag, 17. Mai 2005 10:55
> > > An: Michael Dill; Tim McGrath
> > > Cc: Ubl
> > > Betreff: RE: [ubl] PLENARY REPORT FROM THE UBL TC MEETING IN HANGZHOU
9
> > > MAY - 13 MAY 2005
> > >
> > >
> > > Michael
> > > We find it really useful to have those BBIEs directly under the
document
> > > root.
> > > We don't want to have to create ACC's for every document because we
feel
> > it
> > > isn't necessary, and there are often some essential pieces of data
which
> > > relate specifically to the document. Not allowing them to exist there
> > would
> > > mean that we *would* have to create an ACC for every document.
> > > Is this what you are suggesting?
> > >
> > > Catherine Williams
> > > Technical Manager
> > > PISCES - Connecting Real Estate ... Now
> > > +44 191 230 8094 Office
> > > +44 7947 279780 Mobile
> > > +44 191 226 8920 Fax
> > > catherine.williams@pisces.co.uk
> > >
> > >
> > > This message contains confidential information solely for its intended
> > > recipients and others may not distribute, copy or use it. If you have
> > > received this email in error please tell us either by return e-mail or
> at
> > > the numbers above.  We have used measures to ensure that this email is
> > free
> > > from software viruses. However, in accordance with good practice the
> > > recipient is responsible for ensuring that it is virus free before
> opening
> > > it.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Michael Dill [mailto:dill2@gefeg.com]
> > > Sent: 16 May 2005 22:15
> > > To: Tim McGrath
> > > Cc: Ubl
> > > Subject: AW: [ubl] PLENARY REPORT FROM THE UBL TC MEETING IN HANGZHOU
9
> > > MAY - 13 MAY 2005
> > >
> > >
> > > The minutes show that the F2F was a great and successful one!
> > >
> > > > This will resolve the current inconsistency issue raised by NDR
where
> > > > we
> > > have some BBIEs in documents and not in the Common Basic Components.
For
> > >
> > > Tim,
> > > does this means, that there is a chance to get ride of the stand alone
> > BBIE
> > > directly under the document root? They are some times redundant, what
> > should
> > > never happen in a proper model. This would be great and would remove
one
> > of
> > > the barriers to vote positive for UBL 2.x
> > >
> > >
> > > thanks
> > > Michael
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
> > > Gesendet: Montag, 16. Mai 2005 13:04
> > > An: UBL TC
> > > Betreff: [ubl] PLENARY REPORT FROM THE UBL TC MEETING IN HANGZHOU 9
MAY
> > > - 13 MAY 2005
> > >
> > >
> > > ==========================================================
> > > PLENARY REPORT FROM THE UBL TC MEETING IN HANGZHOU 9 MAY - 13 MAY 2005
> > > ==========================================================
> > > MEETING LOGISTICS
> > >       Hangzhou Huagang HNA Resort,
> > >       No.1 Yanggongti, West Lake District,
> > >       Hangzhou, 310007, P.R.China
> > > PARTICIPANTS
> > >       Tim McGrath(chair)
> > >       Mavis Cournane
> > >       Anne Hendry
> > >       Thomas Lee
> > >       Yukinori Saito
> > >       Sung Hyuk Kim
> > >       Peter Larsen Borresen
> > >       Mikkel Hippe Brun
> > >       Colin Lam
> > >       Sun Ho Kim
> > >       Sun Wenfeng
> > >       Stephen Green  (teleconference Wednesday)
> > >       Jon Bosak (teleconference Monday)
> > >
> > > OUTCOMES
> > >
> > > The UBL Technical Committee greatly appreciate the support of the
> Chinese
> > > National Institute of Standards and in particular Mr Lu Bisong who
> > organized
> > > this meeting in Hangzhou. The meeting facilities and the personal
> > > contributions of CNIS member, Sun Wenfeng were exceptional. Those in
> > > attendance agreed this has been one of the most productive and
enjoyable
> > UBL
> > > meetings to date.
> > >
> > > The primary objectives of this meeting were:
> > > - Hear reports from localization subcommittees and liaisons
> > > - Review UBL 2.0 requirements and schedule
> > > - Work of development of content models for UBL 2.00
> > > - Discuss deployment strategies for UBL in the Asia Pacific region.
> > > - Review of comments received regarding the UBL 1.0 International Data
> > > Dictionary (IDD) CD
> > > - Discussion of possible UBL transition to UN/CEFACT
> > >
> > > 1. Hear reports from localization subcommittees and liaisons CNLSC:The
> > > Digital Trade and Transportation network in HK intends to submit their
> > > document models to UBL. UBL components, types and NDR have been used
but
> > not
> > > all the UBL 1.0 Library Content. DTTN is government subsidized. The
UBL
> > > approach is recommended by the DTTN in HK.
> > >
> > > KRLSC:KRLSC is now discussing financial support with KIEC. KIEC wants
to
> > > accept KRLSC as one of the working groups for the e-document
> > > standardization. The support of KIEC wold have a positive affect on
the
> > > localization of UBL.The government supported E Commerce Internet
> > > forum(ECIF) will receive the draft of the Korean localization effort.
> > There
> > > are also guidelines for UBL applications written in Korean. This
should
> be
> > > announced on the UBL website.
> > >
> > > JPLSC: Has reviewed the mapping study between major Japanese business
> > > documents and UBL. The translation of the UBL data types was confirmed
> by
> > a
> > > 90% match on essential BIEs. The significance of the ECALGA project in
> > Japan
> > > is huge.
> > >
> > > Proposed Danish LSC: Danish adoption of UBL Invoice has been
successful.
> > > Next steps will be to ask UBL to have a Danish Localisation
> > > Subcommittee(European). Implementation of UBL order will be done by
fall
> > of
> > > 2006. A meeting is planned on May 18th to initiate a European forum
> > (perhaps
> > > a European LSC). Attendees from Norway, Sweden, and Britain are
> expected.
> > >
> > > ESLSC: Have built software libraries for UBL in Spain. 200 Companies
are
> > > using the UBL libraries to generate the invoices. Between now and June
> > they
> > > will be going live with 10 companies sending real invoices. In South
> > America
> > > there is an Ecuadorean working group. There is a 10 month plan to
define
> > the
> > > UBL data needs, the pilot project and the dissemination plan.
> > >
> > >
> > >
> > > 2. Review UBL 2.0 requirements and schedule
> > >
> > > Proposed major changes from UBL 1.0 to 2.0:
> > > * Restructuring of the spreadsheet and schema architecture.
> > > * Adding new documents so a extended procurement and certificate of
> origin
> > > application business process supported.
> > > * Adding more Party-types.
> > > * Buyer to buyer information applied.
> > > * Person-type added.
> > > * Incorporated legal requirements for Japan and the EU
> > > * Support of prepayment/recurring payment
> > > * Document references in all document types.
> > > * Enhancement based on localization requirements.
> > > * Better support for customisation.
> > >
> > > The following are comments on the proposed UBL 2.0 extended business
> > process
> > > model for procurement.
> > >
> > > Proposed Sourcing Collaboration
> > > We need a better document name than catalogue as this has caused some
> > > confusion.The most common use case is for a seller to send off a
> catalogue
> > > to various market places. He could send it to a buyer but that would
be
> > > rarer. The catalogue part of the process should not be emphasised, and
> > > should not be an integral part of the process. The request for
quotation
> > and
> > > the quotation are an independent and important part of the process.
The
> > > catalogue question is important between the seller and the marketplace
> but
> > > not between the seller and the buyer.The Danish government would be
> > > interested in sponsoring the development of cataloguing document that
> > > extends the current proposed process. We should split this process
model
> > > into two - one to show the sourcing and the other would be quotation.
> > > Quotation would be a more interesting to Japan.
> > >
> > > Proposed Fulfillment Collaboration
> > > Rectification advice is not a word that is a word that is
recognizable.
> A
> > > better word would be "Correction Advice". We suspect we could just
> resend
> > a
> > > corrected despatch advice (as we do with Order). We may have a revised
> > > Receipt advice as well. Peter Borresen will investigate whether a
> despatch
> > > advice can satisfy the information requirements of a rectification
> advice.
> > >
> > > Proposed Buyer Billing Collaboration
> > > We need to know more about the information flow before a self bill
> invoice
> > > is created, for example, how does the buyer understand what to provide
> in
> > > the self bill invoice. Peter Borresen to investigate with IDA.
> > >
> > > Proposed Seller Billing Collaboration
> > > There is a document missing from the diagram - Account Response. This
> > needs
> > > to be redrawn.
> > >
> > > Proposed Payment Collaboration
> > > There is also a requirement for an acknowledgment at the business
level.
> > > Where an invoice is rejected a message is required to say so or else
the
> > > Seller does not know until he doesn't get paid. We will propose a
> Invoice
> > > Rejection message. Mikkel Brun will design this. It was agreed that
for
> > 2.0
> > > we have to test that we can do a minor release before any formal
release
> > to
> > > ensure that versioning mechanism works. This should be done when we
> > > generate the sample instances. This will be done by the Danish
> > > representatives. Additionally, there will be an editorial team for the
> NDR
> > > document and extra resources to help with NDR activities are
requested.
> > > Mavis was nominated as the editorial team leader to accomplish this.
> > >
> > > Revised Schedule
> > >    17 May 2005 Content team meeting in the Pacific TC calls starts
> > >            processing input from European stakeholders and the
> > >            OASIS Tax XML TC
> > >    18 May 2005 NDR team meeting in the Atlantic TC calls starts
> > >            reviewing NDR issues in light of the decision to
> > >            make all elements global, then takes up code lists.
> > >                Restructure spreadsheet models (see above).
> > >    01 Jun 2005 Finalize requirements/issues list for 2.0
> > >    15 Jun 2005 TC agree requirements/issues list for 2.0
> > >                Begin updating spreadsheet models
> > >                Agree changes to the NDR
> > >    08 Jul 2005 Begin Public Review Number 1 (data model only)
> > >                Load spreadsheets into EDIFIX and test/revise until
> > > synchronized
> > >    01 Jul 2005 GEFEG gets all the schema changes decided so far
> > >                (DavidK goes on vacation last two weeks of July)
> > >    08 Aug 2005 All-week UBL TC meeting in Ottawa hosted by Adobe:
> > >                Review of the spreadsheet and EDIFIX models.
> > >                Comment disposition, Review Number 1; begin final
> > >                schema generation for Review Number 2
> > >    01 Sep 2005 Package assembly for Review Number 2
> > >                Test that we can do a minor release
> > >    15 Sep 2005 Begin Public Review Number 2 (entire package)
> > >    15 Oct 2005 Comment disposition and repackaging
> > >    15 Nov 2005 2.0 internal UBL CD vote begins
> > >    01 Dec 2005 CD approved by start of UBL TC meeting;
> > >                begin OASIS one-month public review (etc.)
> > >
> > > One of the key factors in whether we will meet the timetable is
whether
> we
> > > have the resources to do it. Since 1.0 there are less resources to do
> it.
> > > Mikkel Brun emphasized that meeting these schedules was critical to
> UBL's
> > > acceptance. We also discussed the need for review at critical points
in
> > the
> > > process in which TC wide participation is highly essential. TC review
> may
> > > need to take place on joint calls. To better facilitate work items, we
> > > propose to establish a third weekly call slot (to suit Europe and
Asia).
> > Tim
> > > has offered to chair these calls (if Jon approves).
> > >
> > > 3. Work of development of content models for UBL 2.00
> > > For 2.0 we would like to change the structure of the spreadsheets. The
> > > proposal is to have 3 three layers:
> > > * the documents and any ABIEs only they use,
> > > * common ABIEs (ie used more than once) within a context, and
> > > * core ABIEs.
> > > This will resolve the current inconsistency issue raised by NDR where
we
> > > have some BBIEs in documents and not in the Common Basic Components.
For
> > > example in the current CBC we have ReceivedHandlingUnitReceiptLine
that
> is
> > > not really a CAC becasue it is contextual. It was agreed that
"common"is
> > not
> > > the same as "core". NDR will need to redraw the schema diagram showing
> the
> > > CACs and CBC schemas that implement this, and to provide some naming
> rules
> > > for these. We will try to ensure semantic compatibility with 1.0 and
we
> > > don't intend to change the Data Dictionary (but we will add to it).
> There
> > > may be clarifications or definition changes in the Dictionary.
> > > COML: Crimson Logic have done a lot of the work that UBL will
> incorporate
> > > into the UBL 2.0 Certificate of Origin document. Peter Borresen and
> Thomas
> > > Lee will liaise with Crimson Logic on the suitability for UBL of the
> model
> > > for digital signatures as provided by the COML project. Tim will
> transfer
> > > these requirements onthe UBL 2.0 issues list. IDA Issues: Peter
Borresen
> > and
> > > the European localization group will transfer their requirements into
> the
> > > UBL issues list.
> > >
> > >
> > > 4. Discuss deployment strategies for UBL in the Asia Pacific region.
> JPLSC
> > > will propose a pilot project  with a view to seeing how harmonization
> > could
> > > happen between Japan and other economies. The other LSC
representatives
> > said
> > > that they would need some commerical funding to do this. Mikkel Brun
> will
> > > take this offer up with some Danish companies.
> > >
> > >
> > > 5. Review of comments received regarding the UBL 1.0 International
Data
> > > Dictionary (IDD) CD No comments were recevied so the dscussion moved
> onto
> > > leveraging the value of the IDD. We discussed that the translation of
> the
> > > library content is very useful for the software UI if we could add a
> > "label"
> > > to the metedata for use in forms. It was noted that we now have a UBL
CD
> > > document that will require maintenance. We need a synchronization plan
> to
> > > ensure coordination between the various localization SCs. There will
be
> a
> > > need to translate new entries and to improve translations of existing
> > > entries. One of the attractions of the IDD is that it could be a
> > repository
> > > on a website and the entries would be URIs that could be pointed to.
The
> > > LSCs shared their different approaches in doing translation. In Japan
> > > individual translation was done, and then a peer review took place. In
> > Korea
> > > this was done more in a group with a coordinator. In China, there were
3
> > > phases. First the BIEs were translated, one person did the draft
> > > translation, it was group reviewed, this was just within CNIS this
> > > review.During this process much attention  was paid to the old EDI
> > > translations. The existing translations of EDI were then reviewed by
> > > Industry Experts. In Japan existing EDI translations were also used as
> > basis
> > > for the initial translations. a. Recommendations for new Localization
SC
> > > Generally, an expert would be appointed to perform an initial
> translation.
> > > Attention should be paid to any existing translations of BIEs (e.g.
EDI
> > > translations). The initial translation should then be reviewed by a
> group
> > of
> > > experts who will look at harmonization and semantic integrity. b.
> Changes
> > to
> > > the process required for maintenance We propose to adopt a versioning
> > scheme
> > > to act as an indicator for the change log. Every entry has to be
> versioned
> > > so it is readily identifiable what has changed. c. Changes to the
> process
> > > for translations to the new dictionary entries The environment for
> > > translation will be set up, but we won't apply translation until CD
2.0
> is
> >
> > > finalized. We discussed that a good way of validating the translations
> is
> > to
> > > see that the data when translated is formatted in the right way. For
> this
> > we
> > > need a stylesheet in the different languages. These formatted views
> could
> > > then be used by the LSC review teams to review the translations.
Having
> an
> > > abbreviated label for the output media (see above) would assist in
this
> > > task. We propose to create a project team for this and also support
the
> > > request from HISC for use-case participants.
> > >
> > >
> > > 6. Discussion of possible UBL transition to UN/CEFACT
> > > In a lengthy and considered discussion, all attendess presented their
> > > assessment of the concerns and opportunities of this transition.  The
> key
> > > points were: a. ISO accreditation would be extremely significant for
UBL
> > > adoption in Asia. Both China and Korea automatically adopt and develop
> ISO
> > > standards. If UN/CEFACT can fast track UBL as an ISO standard it would
> be
> > > attractive.  However we are unsure if OASIS and the MOU still offer an
> > > alternative. b. However, the market would be confused if UN/CEFACT
> > published
> > > alternative document schemas. c. The reluctance of UN/CEFACT to
consider
> > > adopting the UBL NDRs does not bode well for integration with other
> > > UN/CEFACT work items. d. Of all the areas for UBL, the UN/eDocs (TBG
??)
> > > appears the most palatable to both parties. e. A key to ongoing
> > development
> > > of UBL will be the willingness of our current memebrs to transition
with
> > it.
> > >
> > >
> > > Calendar review
> > > The Danish, British and other scandinavian governments are meeting on
> May
> > > 19th in Copenhagen to discuss UBL. Peter Borresen will provide details
> to
> > > the list. The ebXML Asia Committee meeting will take place in Hong
Kong
> in
> > > June. Thomas Lee will provide details We will seek a meeting in Europe
> in
> > > early March 2006, and an additional meeting in Korea in the early May
> 2006
> > > if appropriate.
> > >
> > >
> > > Individual Action Items
> > > Peter Borresen:
> > > * will incorporate the IDA requirements in to the 2.0 Issues list
> > > * with Thomas Lee will liaise with Crimson Logic on the suitability
for
> > UBL
> > > of the model for digital signatures as provided by the COML project
> > > * investigate whether a despatch advice can satisfy the information
> > > requirements of a rectification advice
> > > * provide details of the British and other scandinavian governments
> > meeting
> > > on May 19th in Copenhagen to the UBL list.
> > > Saito-san:
> > > * take the current UBL library and divide it in to contexts. Thomas
Lee:
> > > * document new three-level architecture and send to Saito-san.
> > > * upload the DTTN codelist approach paper to the UBL list.
> > > * with Peter Borresen will liaise with Crimson Logic on the
suitability
> > for
> > > UBL of the model for digital signatures as provided by the COML
project
> > > * provide details of ebXML Asia meeting in Hong Kong.
> > > Mavis Cournane:
> > > * lead the discussion in the Atlantic call for the new rules required
> for
> > > the 3 three layers of schemas.
> > > * lead the discussion in NDR about the need to remove any rules that
> would
> > > not be required now that we are adopting the ATG schemas. In that case
> do
> > we
> > > need any UBL NDR rules about the CoreComponent types. Mikkel Brun:
> > > * propose a Invoice Rejection message.
> > > * update extended business process model diagrams
> > > Tim McGrath:
> > > * raise the suggestion that once the NDR work is complete that there
may
> > be
> > > time and resource to pick up the customisation requirements.
> > > * put back missing Account Response document in the Seller Billed
> > Invoicing
> > > diagram.
> > > * transfer COML requirements onto 2.0 issues list
> > > Jon Bosak:
> > > * update UBL web page with link to KRLSC guidelines,
> > >
> > >
> > > --
> > > 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 (coming soon from MIT Press)
> > >
> >
>
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
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>