[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of Atlantic UBL TC call 6 April 2005
MINUTES OF ATLANTIC UBL TC MEETING 15H00 - 17H00 UTC WEDNESDAY 6 APRIL 2005 ATTENDANCE Jon Bosak (chair) Mikkel Brun Marty Burns Tony Coates Mavis Cournane Stephen Green Anne Hendry David Kruppke Sylvia Webb STANDING ITEMS Additions to the calendar (http://ibiblio.org/bosak/ubl/calendar.htm) None. TC meeting in Hangzhou MavisC and AnneH got the message 30 March from CNIS regarding meeting logistics but did not receive the invitation letter sent from CNIS two days earlier. Since both messages were sent from exactly the same address to exactly the same list of addresses, and some of us did receive both of them, the reason for this is a mystery. ACTION: JonB to send invitation letter and logistical information to the whole ubl list. Liaison report: UBL in Denmark MikkelB: More than one million UBL 0.7 invoice messages have now been exchanged in the public sector, and a lot has been learned in the process. An eventual transition to current UBL schemas is in the works. On 18 March, the Danish group presented on their UBL experiences at an IDA workshop; the presentation was well received. The group will also be presenting on their experiences with UBL at the May XTech 2005 conference in Amsterdam. The Danish XML Committee has approved the formation of a Danish UBL Localization Subcommittee and is ready to proceed with its formation within the UBL TC. ACTION: MikkelB to send info (co-chairs, etc.) to JonB; JonB to propose DKLSC formation to the TC. Subcommittee report: SBSC StephenG: The SBS has been updated to what we need for review; a link will be sent out after the SC has had a chance to review the latest draft, which can be found in the documents section of the HISC page. (HISC is being used for this because Kavi will not allow publicly visible documents on the SBSC site.) ACTION: JonB to resume the discussion with Altova. Team report: Code lists TonyC and MartyB have reached an impasse regarding the nature of the CL document. For example, they do not agree on whether there are parts of the CL spec that should only relate to UBL (because of UBL's use of CCTS). JonB: We need to escalate this to the TC. AGREED: We will pick up code list issues after several of us return from New Orleans at our meeting 4 May and then give these issues priority treatment (operating in parallel with the content and localization issues being worked on in Hangzhou the week of 9 May) until we have resolved them. ACTION: MartyB and TonyC to create a briefing package summarizing the issues for the TC and send it out the week of 25 April so that we can prepare for the discussion. NDR WORK SESSION We began a discussion of the issues list posted by Stephen Green: http://lists.oasis-open.org/archives/ubl/200504/msg00003.html We were primarily interested in the impact on users of incorporating the changes suggested by Mark for "UBL 2.0" into what we've been calling "UBL 1.1". Q1 -- Would be easy, since no current 1.0 instances would be affected. Q2 -- Would actually break some instances. Question: what does ATG intend to do here? And do we actually have any lowercase acronyms in element names, or any acronyms with mixed case? AGREED: We need to know from Mark what ATG's position is, and we need to review 1.0 to see what would actually be affected. (Note that there is no Q3.) Q4: Question for Mark: If this is "unenforceable", then why put it in 2.0? Is this rule here for alignment with ATG? Q5: Similar to Q1 in the sense that if it were done, now would be the time to do it. StephenG: This is just badly worded and doesn't need to change. Q6 is resolved. Q7: The SSC says: this appears to be impossible to implement. We find that very odd and need to understand from Eduardo and Arofan what we're missing here. ACTION: JonB to arrange a meeting to discuss this. Q8: It appears that the rule is correct; it's our implementation of it in 1.0 that's in error. DavidK: This wouldn't change element names, just the names of complex types. Question: Can we correct our implementation of the rule without creating backward incompatibility? Appears to depend on whether the processing system is type-aware; if it is, then the corrected schemas would not be backward compatible. JonB: So this is another case where we're clear on what needs to be done but afraid of breaking backwards compatibility. What if we renamed UBL 1.1 to 2.0 and incorporated the corrections that create theoretical incompatibilities but wouldn't actually affect very many users at this point? Arguments for renaming "UBL 1.1" to "UBL 2.0" - It would finesse the current problem we're having implementing 1.1 according to our NDRs for minor versions (though this doesn't actually get us very far, because if there are problems here, they will need to be resolved before we can issue another version anyway) - It would recognize the major expansion of content that we're getting as a result of the IDA/OGC input, the JPLSC/ECALGA input, and the addition of Certificate of Origin; whatever we call it, the next release will be about twice the size of 1.0 - It would allow us to make some technically incompatible changes before they become incompatible in practice; that is, the incompatibilities would affect few users at this time while preventing much larger problems farther down the line - It would align our next release with the ATG CCT schemas - It would allow us to align with ATG NDRs on the issues in which we're already in agreement Arguments against renaming "UBL 1.1" to "UBL 2.0" - It might confuse people who have been discussing the timing of a possible transfer of the UBL work to UN/CEFACT - It might encourage people who think that we have taken the wrong approach with basic NDR choices to lobby us for fundamental changes in the upcoming release instead of waiting for the empirical evidence we will be gathering over the next couple of years of implementation Rebuttal to arguments against renaming "UBL 1.1" to "UBL 2.0" - This kind of relabeling happens all the time in OASIS; look at the ebXML specs - If renaming were really a problem for UN/CEFACT discussions, it would have become apparent in the change from "1.0" in the initial round to "1.1" now, but it appears that the people we're talking to are smart enough to make the adjustment This discussion will be continued next week. Jon
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]