The UBL Tools and Techniques Subcommittee met on Thursday 22 May 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: ========== Chee-Kai Chin Anne HeNDRy Kris Ketels Lisa Seaburg Gunther Stuhec Paul Thorpe Agenda: ======= 1.) Sorting and prioritizing of all requirements 2.) Look for volunteers of the high-prioritized requirement 3.) 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 so we can use UBL XML more efficiently in this tools? 4.) Defining a time schedule for the described steps above (requirements and testing) 5.) Other business 6.) Adjourn 0.) Team Charter "To evaluate and recommend to the UBL TC the tools and techniques to be used in the development, quality assurance, documentation, maintenance, and revision of the the UBL XML data formats, and to write and maintain guidelines reflecting these recommendations." There is a question as to whether or not this charter is intended to cover tools for internal methodology/use only, or is also for external adopters. Gunther stated that the charter of the group is to recommend tools that can be used with the XML schemas (see requirements #14 - #17 below). After we check these things we can see how we might define a tool for modeling business documents. Gunther suggested that we might the change the charter a bit based on requirements from NDRSC and LCSC in three main areas: 1) modeling (part from LCSC mainly) and storing of CCs in databases, for example how user can do adminstration to change these objects 2) XML native databases; XML schema generators like XMLspy 3) generation of the interface itself; generating Java classes, C++ classes efficiently Gunther proposed the questions listed in agenda item #3 also be addressed within the scope of the TTSC charter, for example: a) How we can use NDRSC rules with different tools and apps? - apps like XML native databases, java parsers, SAX/DOM parsers, - like interfaces for SVG, user interfaces - which tools are necessary for our requirements - which tools are necessary for NDR definitions b) Which tools are useful for modeling libraries, which tools are good for defining interfaces, which tools for generating instances from XML schemas, etc. c) Are the NDR definitions useful to define current tool set - are the schemas defined efficiently enough for the tools requirements. Some members of the team raised issues with recommending vendor-specific tools, and problems with vendor involvement, stressing that we should not be recommending specific vendor products, but rather simply stating the requirements/features that tools need to support for UBL. Another key task of TTSC is to look at how to use ND Rules for schema implementation. Gunther suggested we might need to do hand-crafting of schemas for the initial work since the LCSC libaray does not use the new NDRSC rules yet and there are further conflicts in the rules which impact the schemas in a large way and make them very difficult to put in the Perl scirpt. Chee-Kai asked for clarification as to whether Gunther is stating that NDR schema rules are too difficult to implement the way they are now. If so, this would imply a problem with XML schema, not necessarily with the way NDR has defined the schema rules, but this doesn't seem likely. Gunther replied that since we have not tested any of the NDR work in any of the areas that the TTSC is looking at - storing of schemas into databases, for example - that the LCSC should be concentrating on spreadsheets now and defining libraries using spreadsheets only. It makes no sense for LCSC to try to generate schemas now because it would not be useful to do so with the current (.70) ND Rules. When NDR releases a new rule set then we can look at these and see how we can use these with differnt tools and interfaces to help us see at an early stage if the tools are useful. Then, if we find issues with new rules - that it isn't possible to use them efficiently - we should report those to NDRSC. We will do a proof of concept of the NDRSC rules using new tools. Kris asked whether it might not be better to begin by checking the UBL rules against existing tools and generating feedback to NDR based on that. Gunther agreed that we can check against exisitng tools and then say what's difficult with current schemas. We could then also find out what extensions are needed to the tools to do schema generation more efficiently. In the work at SAP it was found it was better to take the Venetian Blind approach which is based on object oriented modeling and other normal Java approaches. TTSC should look at how to implement schemas more efficiently and make sure the NDR rules are helpful and that they don't require too many changes to the tools. Kris noted another example of issues with the schemas they encoutered in their work: when they initially developed their XML solution they had their customers come back to say their messages were far too long. Chee-Kai noted that When the final schemas are published and developers are using them they will use generic tools to work with the schemas, not tools from UBL, so the tools will probably be executed only once - internally to UBL. The tools are meant to support NDR for designing and LCSC for modeling and semantics. We should be helping them change this into normative XML schemas. The issue Kris brings up falls between naming and LCSC, but the tools should implement what NDRSC and LCSC decide. Gunther agreed that the primary thing is to implement NDR rules within the tools - to do generation from xsl into XML schema, graphical models, etc. But, if we can show it's very hard to define applications - that we need a lot of exceptions to do this work, or have a lot of conflicts between the structures because of the rules - then we should look at how we can do this better by redefining the schema. Many developers are ignoring complicated schemas because it is too hard to parse, generate, etc. One of the key issues of future generations of business languages is that you can use it for developing applications efficiently. So we should look at how to genearate apps efficitently using XML schemas. Chee-Kai concurred that if implementations create problems, yes, that needs to be surfaced. However, if we are talking about different ways to write schemas (because XML schema allows implementations in several different ways), this doesn't seem to be a UBL issue that is debated upon by NDR. If we identify a particular way of writing schema to be a problem, yes, we should pass that on to NDR, but it's not our issue to rewrite the schema, because this will be a problem for all people writing schemas, not just UBL. XML schema is a recommendation from W3C and if we are making statement that this is too complicated, that suggests that in general all schemas written this way would have a problem. | Gunther replied that he is not discussing the options of designing schemas, just raising the issue that the current definitions of NDRSC will be an implementation problem (eg. local vs. global, venetian blind, etc). Otherwise implementers of UBL schemas in applicationss will see it is too complicated and they'll ignore UBL which will be a problem. For now everyone should look at tools, and then if there are problems in implemenation, we'll raise these to NDRSC. Otherwise, if we see tools are not useful because features are missing, then we can write some recommendations for further features for UBL to allow more effective use of tools. In the meantime we can write some quick tools for testing/poc, but not develop complicated apps becasue the time is short. Chee-Kai asked whether there is a way to quantify the complication to which Gunther is referring, because if this was proposed to the public there will be questions asking to clarify the complications, since to some it may be complicated, but not to others. Gunther replied with a few complications: a) One issue is that in the future we expect that people will be defining libraries using CCTS, not XML. They will be defining dictionary entry names. These are currently separated by dashes/points; these must be always unique. But now you can write tools to generate tag names from dictionary entry names automatically. Maybe if we can see that this is very complicated because with the current global tag names we need to do double-checking, validation, etc. we can say that we must change tag names from global delcared. b) another complication is that normally you use types to generate Java classes to use objects inside the Java environment. But now we have globally declared elements. 2.) Look for volunteers of the high-prioritized requirement Rescheduled for next meeting. 3.) 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 so we can use UBL XML more efficiently in this tools? Rescheduled for next meeting. 4.) Defining a time schedule for the described steps above (requirements and testing) Rescheduled for next meeting. 5.) Other business Schedule for Monteal: Weekly meetings, Thursdays, 1-1/2 hours, 7:30 am PDT. Next week we'll discuss modifying the charter. 6.) Adjourn: 17:00 GMT TTSC Requirements (from ttsc and NDRSC): ================== 1.) non-proprietary storage format 2.) availability on multiple platforms 3.) configurable to syntax rules 4.) configurable to customization rules 5.) provides version control 6.) requires no manual editing 7.) supports XMI change format 8.) is an integrated tool set 9.) provides collabortive central source repository 10.) enforces a controlled vocabulary 11.) provides a single data/source repository 12.) low (no) cost 13.) Modelling systems 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 a.) native XML Databases b.) flat file c.) SQL Databases 15.) Transformation systems - Tools for writing efficient XSLT scripts for transforming into HTML or another kind XML based business language 16.) Intefaces generation systems 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 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