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] new work item for UBL


Michael,

> 1. Is UBL compliant with ISO15000-5 CCTS and ISO 11179 or not?

Partially compliant with CCTS, fully compliant with ISO 11179

> 2. Is this compliance considered to be important by the TC?

It is one of our guiding principles.

WRT the remainder of your email, although I share many of your sentiments, I am not sure how I can equate the issues you raise to the discussion at hand.  You may want to raise each of your points in separate emails so they don't get lost in the discussions but can maintain their own independent discussion threads.

Mark

> -----Original Message-----
> From: Michael Dill [mailto:dill2@gefeg.com] 
> Sent: Wednesday, May 18, 2005 7:04 AM
> To: Stephen Green; Ubl
> 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_workgr
> oups.php 
> 
> 


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