[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] new work item for UBL
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]