[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-cmsc] Conference Call Minutes 06/DEC/01
Attendees: Bill Burcham - YES (jointed at x:15) Dave Carlson Mark Crawford Matt Gertner (chair) - YES Arofan Gregory Eduardo Gutentag - YES Eve Maler - YES (joined at x:08) Gunther Stuhec Also attending as an observer was Dale McKay. (1) Matt raises the issue of the dependencies of context rules on work in the NDR SC: - Schema language - Derivation features - Additive vs. substractive methodology Eduardo points out that the decision not to use any derivation mechanism would remove a lot of these dependencies. Eve supports the assertion that we should be defining a transformation that is not dependent on derivation. In addition, there are examples (like extending code lists) that require ad hoc methods anyway. Matt mentions three possibilities: 1) No derivation, just a transformation. 2) Use of XSD because of extension and restriction features. 3) Coordinate with RELAX NG to create a type derivation mechanism that better integrates business requirements. Eduardo points out that the ebTWG is using RELAX NG for their schema modeling. Dale maintains that we have no chance of imposing RELAX NG, so we should accept XSD and work around the limitations. Eduardo says that ebXML CC context metholodgy has no dependencies on XSD. Matt points out that the decision of using restriction is important nonetheless. Eduardo: Yes, but codelist extension is required also and this is not supported in XSD. Discussion of separating the issues of extension methodology from the schema issues (especially derivation) and pursuing in separate threads. General agreement. Discussion of whether to move the extension position paper to the CM SC. Depends on whether many members of the NDR SC who are not in the CM SC are interested in these issues. General agreement that XSD will be the standard language for core component and BIE modeling. Eduardo: We should wait to see if compelling reasons arise for preferring RELAX NG over XSD. Eve points out that it would be very useful to have RELAX NG versions of schemas since there is a formal process for determining unions and intersections of schemas. Also, further types of extension not supported by XSD can be cleanly layered on top of RELAX NG. General agreement that for these reasons we should at least ensure that nothing in our design precludes use of RELAX NG. Matt asks whether we want to suggest that we take over the work of the NDR SC on the extension positioning paper since we have more bandwidth. Eduardo and Eve don't see a problem with it. Matt as chair will send a mail to the NDR SC suggesting this step, and see if anyone has a problem with it. (2) Matt states the problem, which is that no one in the CM SC is volunteering to develop use cases for the context extension methodology. Some informal discussions has led him to believe that it might be better to turn to the Core Library SC to do this. Eduardo reinforces this by pointing out that the business types also don't like it when geeks come up with use cases that aren't realistic in the real world. Matt will write to Tim directly, copying Arofan, and ask to what extent they would be able to help us with the use cases. Suggestion to copy Sue as well. (3) Discussion of next steps. Review of issues originally raised on list and decisions so far: 1) Yes, the Vienna document will be the basis of our work. 2) Should we use XSD derivation? Continue to discuss but decouple from specification of extension mechanism. 3) Assume that we will need features for both additive and subtractive extension. 4) An adhoc XML format will be used for the specification of context rules. 5) Eve's suggestion for using text matching to handle hierarchical context driver values met with some approval but does not solve all issues. Discussion will be continued on the mailing list. 6) No need for assembly rules. 7) We choose good names that make sense and not bind them to XSD. 8) We should make use cases and test them against the Vienna doc to find any "broken" features. Next steps: - Continue to discuss open issues listed above (derivation and hierarchical context drivers). - Take over work on Arofan's positioning paper if the NDR SC agrees. - Solicit use cases from the Core Library SC.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC