ubl — archive

[Jon Bosak]

UBL TC MINUTES FOR MONDAY 14 AUGUST 2006 Members attending in person: Jon Bosak (chair) Mavis Cournane Mike Grimley Andy Schoka Paul Thorpe Members attending by phone: None. The conference line was live from about 09:05 to about 11:45 and then again from about 13:30 to 15:00. One person reported difficulty dialing in, but a test from a cell phone confirmed that the bridge was up at our usual number (see the agenda). Welcome and overview No SC or team reports. Normative schedule review See http://lists.oasis-open.org/archives/ubl/200608/msg00031.html JB: This is a very tight schedule. There are a lot of items to hand in with the submission. In particular, we need organizational members to testify that they are "successfully using" UBL 2.0 per the OASIS TC process. Note that the meaning of "successfully using" is designedly fairly vague and can cover anything from active consideration to full production. Several members representing OASIS organizations committed to getting such a statement from their respective employers. ACTION: JB to put out a notice to the list requesting "successful use" statements. Support package structure and scheduling The group went through the new support schedule template and briefly discussed each item. It turns out that we need a lot of status reports before we can plan much further, specifically the following: Danish use cases and example instances (Borresen) Sample business rules expressed in schematron (Borresen) Output stylesheets (maybe by reference) (Holman) Input Xforms (Borresen) UML and EF data models (pointers) (McGrath) We hope to have better information on the status of these items when joined by other TC members later in the week. AGREED that we want to set a date of completion for the first release of the Support Package after looking at the status reports and then to publish whatever's ready by that date, in keeping with our previously agreed plan to publish the SP periodically as a living document. The NDR row was moved from the first draft of the normative schedule to the top of the SP schedule and moved forward two weeks so that the first 60-day review can be finished in time for comment disposition in Singapore. Further discussion of the Support Package schedule was deferred till Wednesday. IPR transition Refer to the IPR Transition page at OASIS: http://www.oasis-open.org/who/ipr/ipr_transition_policy.php JB: Under the IPR policy adopted by OASIS April 2005, we get till April 2007 to either adopt a revised IPR policy of our choice or automatically go out of existence. So we really ought to get this over with. We get three choices for the TC's IPR policy: RAND ("Reasonable and Non-Discriminatory," i.e., undefined); Royalty-free on RAND terms; and Royalty-free on Limited Terms. RAND is directly contrary to the charter of the UBL TC, which has always promised users a royalty-free Standard. Of the two remaining IPR policies, the one that's closest in intent to our historical charter is RF on Limited Terms. (The name refers to limits put on the licensor, not the licensee.) AGREED: Recommend to the TC this week that we request OASIS to transition the UBL TC to RF on Limited Terms and ballot the question next week (beginning 21 August). Instance rules in NDRs IND1-IND7 state rules for UBL instances. After some discussion, it was determined that these items are not schema naming or schema design rules. Rather, they are document constraints of the sort that would be provided by the schemas if the schema language that we are using was capable of supporting them. AGREED to move the IND rules out of the NDR document and put them into the UBL spec as "additional constraints," noting that we are not creating new rules here but rather just moving them in from an existing OASIS Standard (1.0 NDR). [We later realized that we could also keep these in the NDR document with a suitable adjustment to the language that sets forth the purpose of the document.] AGREED to remove RED1 from the NDRs. The UBLVersion element Once we untangled the language relating to this element from the question of instance rules in NDRs, there were seen to be two issues here: the direct problem that the element was supposed to be mandatory (minoccurs=1) but through a clerical error ended up optional (minoccurs=0), and the wider problem of how the application is supposed to choose a schema based on the value of UBLVersion when it must already have chosen a schema to begin parsing the document. And this in turn made us realize that we weren't entirely clear on the use cases this element was intended to address. We also discussed the reasoning behind giving the element a default value rather than none at all. Here's a decision tree we started to sketch out in order to understand the question of default value vs. no default value. Scenario I: A 2.0 document is sent to a 2.1 system (and the 2.0 data is enough for the receiver's business process) Case 1: A default value for UBLVersion is hardwired into the validating schemas Alternative A: The element is empty: then the 2.1 validating schema incorrectly contributes "2.1" to the value of UBLVersion (this is a good reason for questioning the declaration of a default value) Alternative B: The element correctly says "2.0": then the receiver's software is given the correct versioning info and can act on it (if it's got some way of peeking at the value before beginning the parse) Case 2: A default value for UBLVersion is not hardwired into the validating schemas Alternative A: The element is empty: then the 2.1 validating schema doesn't know what it's got Alternative B: The element correctly says "2.0": then the receiver's software is given the correct versioning info and can act on it (if it's got some way of peeking at the value before beginning the parse) Scenario II: A 2.1 document is sent to a 2.0 system (and the receiver is OK without knowing the meaning of the elements in the document that were added in 2.1) If there are any 2.1 elements, the document won't validate against the receiver's 2.0 schema regardless of the value of UBLVersion MB contributed the thought that the value could be declared as a decimal with format "X.X" and given a range constraint. For example, 2.0 schemas could require UBLVersion to be of type decimal with a minimum value of 2.0 and a maximum value of 2.0; 2.1 schemas could require it to have a minimum value of 2.0 and a maximum value of 2.1; etc. This would eliminate the problems associated with an empty UBLVersion element. At this point we decided to postpone further consideration of this issue till later in the week in order to get other members into the discussion. We noted that VER15 language will need to be revised to reflect what's been correctly specified in the schemas. Jon