[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-cmsc] Minutes from 10-APR-02 Call
Attendees: Bill Burcham YES (left at X:26) Dave Carlson Mark Crawford YES Fabrice Desr? Matt Gertner YES Arofan Gregory YES Phil Griffin Eduardo Gutentag YES Eve Maler YES Dale McKay Aidan Shackleton Gunther Stuhec Chandra Tamirisa Paul Thorpe YES Marion Royal joined as an observer at X:13. Quorum reached at X:09 --- (1) Review of use case status Use cases from January face-to-face are compiled and on the portal. Mainly the use cases come from the LC SC. Comments have been logged from the Barcelona face-to-face and a subsequent call with Matt, Bill, Eduardo and Paul. The comments will be added to the portal before the next call. Arofan says that they are not really use cases because they make too many assumptions about the actual document formats. Matt says that it is probably not realistic to compile use cases that are divorced from all assumptions, but it is true that a lot of the use cases are not that useful or overlap with others. Matt suggests that comments to the LC SC on specific schemas could be caught by Arofan, as the liaison, could catch these cases and transmit them to the CM SC. Eve suggests that we write test cases to validate the use cases. Matt extends this possibly to a preliminary spec based on our expert knowledge and current use cases. Arofan proposes using xCBL to assist in test cases while we wait for the LC SC to produce additional document formats beyond the current Order (which could already be used for testing) Eduardo sees a problem since the rules may depend on the final decision of how to structure the derivation relationships (DWP, TAAT, Paella, etc.). Arofan suggests that Eduardo's point might be very useful in validating the advantages of Paella vs. TAAT. Eduardo responds that we will have to simulate an engine every time we do a case. A: This is exactly what we are trying to evaluate. Eve: We could group cases into categories and associate with types of rules like "add an element". Matt: Excellent idea, although the coverage is not that broad. New cases can be folded in and are unlikely to invalidate the entire approach. A: We have gathered use cases that represent how documents are actually modified according to context. We need to evaluate more complex cases such as applying several rules to a single document in order to tackle issues like rule ordering, etc. M: Let's define a couple of complex test cases and assign to-dos for two people to run these cases using TAAT and Paella so we can compare. Inputs: schema, context values for several drivers and a set of rules taken from the use cases Outputs: modified schema, formal rules A: Let's clean up the use cases, identify patterns and take representative cases, rather than applying the same kind of rules over and over. Action: Clean up use cases and identify patterns -- Matt Action: Create test cases based on different combinations of context drivers -- Arofan Action: Work through test cases using TAAT -- Eduardo Action: Work through test cases using Paella -- Bill Action items may be revised and responsibilities reallocated once preliminary work is done. (2) DWP/TAAT/Paella issues General agreement that DWP has been subsumed by Paella. Basic agreement that the concepts of Paella are understood, although some refinement may be necessary. Discussion postponed until Bill can participate. Eve: I am concerned that until we work through a TAAT example, I don't have high confidence that it will have more success than other methods that the propagation of changes up the document hierachy can be avoided. M: We agreed on the March 29th call that to change the type of a parent is absolutely right and correct when a child type is changed. E: We made a choice to go with local elements, so only types, not elements are reusable. This means that all parent types must be totally redeclared and cannot be derived from the original parent type. A: TAAT solves this problem because the new type can copy the content of the old type, but there is no real derivation relationship there. The attraction is that Paella may be too complex for developers to understand, hampering adoption of UBL. E: We should get more input from outside developers before we assume this. M: Maybe we can use TAAT in order to create the context rule methodology, use Paella as a "workaround" in the short , middle and possibly long term in order to use XSD derivation, and then lobby for a derivation mechanism that meets our requirements better in the longest term. Doesn't refinement do this? Needs more investigation. Action: Create simple TAAT case that will guide further discussion -- Eduardo Action: Write article outlining problems with XSD derivation in relation to UBL, investigate whether refinement covers this case -- Matt (3) Other issues Postponed until next call. (4) Planning for authoring spec Will be addressed after next action items are completed. --- Call ended at Y:06
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC