The UBL Tools and Techniques Subcommittee met on Thursday June 30 2003 at 15:00 GMT. U.S. domestic toll-free number: (866)839-8145 Int. access/caller paid number: (865)524-6352 Access code: 5705229 Attendees: TTSC Members: Dave Carlson - Chee-Kai Chin Y Arofan Gregory - Lisa Seaburg Y Paul Thorpe Y Gunther Stuhec Y Eduardo Gutentag - Anne Hendry Y There is a quorum. Anne will take minutes. Agenda: A.) Talking about the charter There is quite a bit of other work to do that is higher priority than reviewing the charter, so unless there are serious objections to it we will go ahead for now with the current charter: Charter: To evaluate and recommend to the TC the tools and techniques to be used in the development, quality assurance, documentation, maintenance, and revision of the UBL XML data formats, and write and maintain guidelines reflecting these recommendations. Everyone present was in agreement to keep the charter as is. B.) Sorting and prioritizing of all tool requirements In general we will classify the requirements into A (high), B (medium), and C (low). We agreed that the [schema] Processing tool requirements are highest priority (A), since there is immediate effort needed to help get the schema development tools working for the .80 and 1.0 releases, and also to help clarify the NDR rules. The Modeling tool reqirements are medium priority (B). Requirements ============ 1.) non-proprietary storage format: Priority B. 2.) availability on multiple platforms: Priority B. It was undecided whether or not this includes instance generation. Otherwise we will be mainly using Java and Perl only, which are cross-platform, so there should be no problem. 3.) configurable to syntax rules: Priority B Vendor tools must be configurable to UBL rules. 4.) configurable to customization rules: Priorize B This refers to context-based modeling. 5.) provides version control: Priority A This relates to file versioning and source control more than to schema or model versioning - the abililty of several members to edit files concurrently to complete the UBL releases. 6.) requires no manual editing: Priority B Should tools be based on UML? Gunther has begun tools which use SVG to model and generate XML schemas and store them in a native XML database. Poseidon and Objecteering are free to a point, but have no xml interfaces - you can't exchange between UML class diagrams and XML schemas without having to buy additional XML components. We need to understand how to store models in a database and how to generate context-based models. There seem to be two areas we need to address: - modeling system tools - processing tools Gunther suggested to write two proposals - one on each of these two areas - how to approach from the tools point of view. There are several aspects to these, such as working through a web browser or some other text application or by a direct interface to another application, generating instance-processing systems, etc. Chee-Kai noted that he has already developed Java classes that generate UBL-conformant instances and a simple instance storing interface. This was done for 0p70 - user data was entered via a Java text GUI which is saved as a UBL-conformant schema instance. This is not a processing system in terms of massaging data later on, though that piece could be done later. Also, FPSC is focused on generation of presentation formats (transforming instances into UN edocs, XSL FOs, etc.) but we can say we could write a presentation-based generator. Chee-Kai stated that it would be more useful for TTSC to recommend best-practices in terms of XML-related generation (eg. performance in container issue). Chee-Kai thought that it would be beneficial to revisit what TTSC is trying to deliver. A document is nice, but it may or may not be a formal normative document. In particular the requirements currently are a mixture of LC and instance processing rquirements. In addition, people will do whatver is a good tradeoff bewteen cost and usability, so it's not something the TTSC would be able to mandate. 7.) supports XMI change format: Priority B? 8.) is an integrated tool set: Priority B? Gunther noted that GEFEG has made an interface for generation of XML schemas from xsl files and backwards; we could do a proof of concept with this. Anne noted that a main criteria for any tool we use within UBL is that it is free and has no lingering IP issues. Gunther will ask about this in the CSC on Wednesday. 9.) provides collabortive central source repository: Priority B Central cvs/rccs-type environment. 10.) enforces a controlled vocabulary: Priority B 11.) provides a single data/source repository: Priority B 12.) low (no) cost: Priority A 13.) Modelling systems: Priority B a.) based on XML Schemas (like XML Spy) b.) based on UML Class Diagrams or graphical representation of the core components (may be based on SVG) 14.) Storage systems: Priority A a.) native XML Databases b.) flat file c.) SQL Databases 15.) Transformation systems: Priority B Tools for writing efficient XSLT scripts for transforming into HTML or another kind XML-based business language 16.) Interfaces generation systems: Priority A a.) Automatic generation of Java-Classes b.) Automatic generation of C++-Classes c.) Automatic generation of Perl-Classes d.) Tools for generating user interfaces automatically which are based on UBL XML Schemas It was noted that many tools can do the things listed above but we are not recommending tools - only stating what the tools should do. Anyone playing with UBL schemas doing development will already be using tools that support development in these languages. So there is not much value in developing recommendations in these areas. It was agreed that we don't need the processing tools paper that was discussed in #6 above. Gunther propsed then to write a first draft of the paper on schema modeling. Chee-Kai noted that it was important for longevity of this work to connect any modeling proposal to contextualization. Any modeling paper should refer to the way contextualization is being recommended, otherwise there is no value of this paper because there is nothing particularly special about schema modeling outside the context of UBL that people can't read up on themelves. This should be part of #18. 17.) Schema generation systems - Generation of UBL based XML Schemas from and to a.) UML tools, b.) Excel-spreadsheet, c.) Java, d.) C++, e.) Perl-Classes 18.) Tools for contextualization of schemas (eg. to local text): Priority B C.) Look for volunteers of the high-prioritized requirement Anne raised the question of who implements the tools for creating the schemas. Revisiting the TTSC charter it doesn't say anything about implementing anything, it just talks about recommending. So if the TTSC is not responsible for any implementations, who is? This is the top priority of the UBL TC right now - to get the releases out the door. So far there has been no talk in the TTSC meetings of working on the immediate need - the schema generation tools and review and implementation of the N&D Rules. This needs to be addressed. Everyone agrees that the higher priority is to test existing tools and ensure they generate correct schemas according to current NDR rules. It is also important to create recommendations on how to develop tools for modeling, but that should wait for now because everyone is too involved in building .80 to review any proposals that don't relate to the immediate work. Gunther will wait until after we develop the .80 release to generate the proposal on modeling. Gunther voiced concern that N&D rules are still changing each week, which makes it hard to build tools using the new rules. Also, all rules in the NDR Rules checklist are not as simple as what is being voted on, since the rules have been developed over time with many contributors/nuances. Lisa stated that NDR is reviewing rules in quorum, so they are updating them weekly, mostly for clarification. However the rules in the NDR Rules Checklist that are noted as 'ACCEPTED' (in the comment column) will not undergo further NDR review/changes (other than those to address issues raised with a rule). Gunther agreed to run the Perl script using the new rules as a cross-check for the work that Chee-Kai has been doing. This way we will have two views of the new rules - looking at both the Perl script and Chee-Kai's tools. All voted rules from NDR group should be implemented in both tools. D.) Every volunteer should proof the following: - which tools are useful for our requirements? - which features of the tools are useful for our requirements? - which steps can be done manually or automatically? - which features must be added for our requirements? - which developments must we do (tools, functions) that we can use UBL XML in this tools? - which NDR rules must be changed that we can use UBL XML more efficiently in this tools? Rescheduled to next meeting. E.) Defining a time schedule for the described steps above (requirements and testings) Rescheduled to next meeting. F.) Other business None. G.) Adjourn: 17:35 GMT