Subject: minutes from UBL Pacific Software SC meeting, 10 June 2004
The UBL Software Subcommittee met on 10 June 2004 17:00 UTC (9 am Calif, 1:00 Singapore) http://www.timeanddate.com/worldclock/fixedtime.html?day10&month=6&year=2004&hour=17&min=0&sec=0&p1=0 ##################################################### STANDING INFORMATION FOR UBL CONFERENCE CALLS U.S. domestic toll-free number: (866)839-8145 Int. access/caller paid number: (865)524-6352 Access code: 5705229 ##################################################### Attendees: Stephen Green Michael Grimley Anne Hendrdy Bill Meadows Lisa Seaburg Ray Seddigh Sylvia Webb Agenda: 1. Welcome from Chair, Roll, Minutes, Agenda Agenda accepted. New alias: firstname.lastname@example.org 2. HISC recap (Stephen) The HISC Charter is tentatively agreed, but the final decision is next week. Fabio is Co-Chair. Went through 4 items as issues/bugs with forms package (not schemas). These should be added to the FAQ. See list posting on June 9th. AI: Anne get this into FAQ. XPaths output is very bulky so should not be included in package. Will Ken make xpath tool available? AI: Stephen ask Ken about sharing tool. Discussion on certification: UNeDocs is standard for physical paper documents. The UNeDocs template for pdf output provides a space for signatures. In the London meeting a year ago, when the inclusion of digital signatures in UBL was raised by David Burdett in London, the decision was that this was beyond the scope of UBL - that this would be handled best in the message layer. Therefore the only signature accompanying a UBL messge at the present is the one provided by the envelope, as in ebms, not in the document. This is not part of our remit, but perhaps we should have this in the FAQ. The larger question is how do we align with unedocs in this area? We shouldn't provide for certification of the message. By not having this in the document are we stopping any certification at the document level? Are we desirous of merging UBL with UNeDocs, and at what level? Ken is noting this as part of the HISC discussion issues. 2. Charter discussion 1. To create UBL schemas from models created by the UBL TC and continue to evaluate tools for this process. Agreed. We will need Michael's thoughts on how best to make 1.1 happen: through derivation? Perhaps a derivation methodology should be developed? It should start with the models. 1.1 will be different than changes for a future major release. Since this is mostly done in the model there should be no impact that would be an issue with the rules. Stephen will check to see. Sylvia noted that the current version of EDIFIX handles what we might need for 1.1 - can extend and add to the CAC and CDC. We will need documentation for the changes. Release Notes. 2. To promote a forum for the sharing of UBL implementation experience, for feedback to UBL TC and implementors. Agreed. Members should send ideas on implementation discussion to Stephen/Anne for inclusion in agenda. Make sure at least one implementation is discussed each week. We need to ensure that people are aware that what they share is done so with understndaing that it has no encumberances, and is public. Sylvia mentioned that there is a standard anti-trust statement (no colusion, etc, is open forum, info shared whithin certain boundaries) that might be used. We discussed how this might tie in with the OASIS IP policy, and what that is at the moment. AI: Anne ask Jon to decide how to address IP and similar issues as we try to provide an open forum for implementors to speak about their experiences, work, etc. 3. To document wish list requirements for UBL software based on UBL user/implementor and UBL TC needs. Agreed, with the reminder that this is about software (not UBL iteself). 4. To develop FAQ (questions/answers from users, troubleshooting). Agreed. AI: Sylvia/Bill/Anne to cull questions from 3 lists (comment, ubl, ubl-dev) and send, first pass at least, to SSC list by Wed 16th EOB. 5. To document basic information on using vanilla UBL. Agreed. Yes, this is sorely needed and would be very useful if we begin by drawing together current experience (eg. Sylvia, Catherine, Stephen Parker, Stephen Green) with implementors. Stephen mentioned the recent 'Tower of Babel' article by Peter Abrahams noting the terseness of the definitions. This was originally due to the 255 character limitation in the tools (ODBC driver?) but we no longer need to be careful of this. We do need more extensive documentation - beginning with expansion of the description in the definitions. Whether this is done in the spreadsheets or elsewhere is not so much the issue as that it is done. AI: Anne respond to Stephen's email on definitions from Reusable. If we begin with the most commonly used entities/elements, this could be part of the FAQ (could have faq as attachment to each line item, like our original 'analyst notes' colunm). This could be put together for each item - comments relating to that - in a 'hints and tips' doc. We need some way to go beyond the definition to say, for example, "When there's a taxpoint date you should also have other tax info, and these are the relevant other entities'." This is the type of document Sylvia has envisioned as an evolution of the FAQ. Sylvia also mentioned that EDIFIX has a way to capture this information and present it in many forms: rtf, html, pdf. What is there now is taken from the definitions and is quite small compared to what could be there. EF goes through each entity and has a whole page available for addtional documentation of any form. Anne suggested we could do a middle documentation tier (something between the current definitions and the full EDIFIX html doc set) that could be sent with the release. Then the full documentation could be put on the web site. Action: We will start this project with the FAQ and the table Stephen compiled of Reusable definitions. This can then be evolved into what we have described. 6. To actively represent UBL goals to software implementors. Ray asked for a clarification of the audiences of this SC. Assume the TC, the impelmentors, and users. Stephen stresssed the need to garner support from the Big 4, such as PriceWaterhouseCoopers. Ray mentioned the PWC was doing reviews of standards, but there needs to be some incentive for these businesses to apply resources to this. What is the payback for large companies to adopt this technology? Stephen will find a paper written at PWC some time ago which was influential in European and talked about keeping elecronic invoicing simple. This would be very helpful for implementors, such as CECID. Sylvia mentioned that it would be helpful to have an article from an influential group such as Gartner. Discussion ensued on how we can formulate a good marketing position to take to analysts and large influential companies and organizations to clearly show the value of UBL to them - how they can leverage it. Need 4 or 5 selling points for UBL, showing 2 or 3 successful implemenatations. We have to have something where we can say "Use UBL and you will get xyz benefit.", a statement of benefits. Final conclusion is that we need a marketing effort. Not sure if the Marketing SC is still functioning - don't think so - so Ray and Stephen will draft an approach to this problem to be submitted to the TC with a request to start such an activity specifically to address the needs outlined above: the promotion/adoption of UBL. We also need to make sure we address the appropriate groups, not just focus on one or two: big industries, smaller inducstreis, consultants. This should be added to the charter: to create repository of benefits acrued by people who are currently implementing ubl. So you then have list of why people are using UBL. This is like bullet number 8 in our charter, but is more marketing focused - using information to target marketing areas. Ray will follow up and send some initial thoughts to the alias in the next few days to get the discussion going. Stephen will talk to others about what they'd like to see in the marketing area. All send thoughts on this. 7. To maintain UBL tools information on a designated web site. 8. To document UBL use (type of users, types of use, case studies, user input on best practices, etc.). Useful information: how many people are on ubl-dev; other stats such as visitors, etc. We should develop liaison relationships with other TCs such as E-Gov and TaxXML - TaXML jsut finished draft position paper saying they will monotor UBL. AI: Anne send eamil to scott mcgrath to find out how many ubl-dev subscribers. AI: sylvia send email to taxml - Michael Roitman - to invite them. AI: Anne ask Jon and Mark for liaison or contact via email with egov. Imlementations: CECID; HK gov - is open source and could be used by others. Denmark portal - mickkel bruin; should try to find out. AI: Anne begin this converstation with Jon. 3. Meeting time(s) OK. 4. Other business - Stephen concentrating this week on the small business profile. Ray thought this will be very important for adoption. AI: Anne update member list. Action Items: 20040610-01: Anne get issues list from HISC posting on 6/9 into issues FAQ. 20040610-02: Stephen ask Ken about sharing XPath tool with TC. 20040610-03: Stephen check NDRs to see how they may relate to minor and major release changes. 20040610-04: Anne ask Jon about IP and other statements we might want to add as boiler plate for discussions and written material (minutes,etc). 20040610-05: Bill/Sylvia/Anne review UBL mail lists for FAQ and Issues. Send first pass to SSC by EOB PT Wednesday. 20040610-06: Anne respond to Stephen's email on definitions from Reusable. 20040610-07: Stephen send out document from PWC supporting 'simple invoicing'. 20040610-08: Ray send out initial thoughts on goals for a UBL marketing activity. 20040610-09: Anne send eamil to scott mcgrath to find out how many ubl-dev subscribers. 20040610-10: Sylvia send email to Michael Roitman to invite TaxML to liaison with UBL. 20040610-11: Anne ask Jon and Mark for liaison or contact via email with E-Gov TC. 20040610-12: Anne begin this converstation through Jon with Danish UBL implementors. 20040610-13: Anne update member list.