The UBL Tools and Techniques Subcommittee met on Thursday 22 May 2003. 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 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 write and maintain guidelines reflecting these recommendations." Chee-Kai / Kris: Are tools only for internal methodology, or also for external adopters? Gunther: Questions we should ask of tool set: 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 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? Sometimes seemed from London that the schemas are not defined efficiently enough for requirements of tools. Maybe we can the change charter a bit based on requirements from ndrsc and lcsc. Using that I can see 3 parts: 1) modeling part from lcsc mainly, and storing of ccs in databases; expression of xmi; lcsc focusing on modeling part so we need to look at how to show ccs efficiently, for example; how user can do adminstration to change these 2) xml native datgabases; xml schema generators like xmlspy 3) generation of interface itself; generating Java classes, C++ classes efficiently The key issue of ttsc is to look at how to use rules to do implementation. Paul: Is it the charter of our group to come up with guidelines on how to create these artifacts, or to recommend tools on the market that will enable us to create interfaces, etc.? Gunther: The second - recommend tools, not so much guidelines, on how we can use the xml schemas with differnt tools (see requiremetns #14 - #17 below) After we check these things we can see how we might define a tool for modeling some business documents and for changing xml documents. Paul: We should be able to determine how a product should behave, without specifying the exact product, though - just state requirements/features that tools need to support to do what we want to do. Chee-Kai: Yes, TTSC should not itself endorse certain products - this might get vendors involved in a way that is not actually beneficial to the TC. Gunther: We need to support xml schemas, which come from ndrsc rules. We might need to do hand-crating of schemas for a first step, though, then see if xml schemas are useful for modeling. Because if you look to lcsc library, you see that this libaray does not use the new ndrsc rules; there are also further conflicts which impact the schemas in a large way, that make it difficult to put in the perl scirpt. So, that's why I say we may need hand-crafted schemas based on ndr rules for the initial work. Chee-Kai: Are you saying that ndr schema rules are too difficult to implement now, so we should hand-craft them for now? Gunther: Since we have not tested any of the ndr stuff - storing of schemas into databases - lcsc should be concentrating on spreadsheets now and defining libraries using spreadsheets only. It makes no sense for lcsc to look at the schemas now becuase that's not yet useful. We have to look at how we define xml schemas based on the new rules of ndrsc 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. 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 on ndrsc rules. Kris: What about checking ubl against existing tools that are out there and generate feedback to ndr based on that? Gunther: Yes, we can check against exisitng tools and say what's difficult with current schemas and also say what extensions are need to the tools to do our work more efficiently (generate schemas). But it is necessary to find problems out now. In our work we found it was better to take the venetian blind approach - based on object oriented modeling approach and other normal java approaches. Kris: An example we encoutered was that we initially developed our xml solution and had our customers come back to say our messages were way too long. Gunther: Yes, we need to look at how to implement schemas more efficitenly and make sure the ndr rules are helpful, that they don't require too many changes. Chee-Kai: When final schemas are published and developers are using them, they will use generic tools. The internal tools are probobaly only executed once. The tools are meant to support ndr for designing and lcsc for modeling/semantics. We should be helping them change this into normative xml schemas. Issue Kris brings up falls between naming and lcsc, but the tools should implement what ndrsc and lcsc decide. Gunther: Yes, the primary thing is to implement ndr rules thorugh the tools, to do generation from xsl into xml schema, graphical modeling tools, etc. But, if we can see it's very hard to define apps - that we need a lot of exceptions to do the work, or have a lot of conflicts between the structures - 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 apps efficiently. So we should look at how to genearate apps efficitently using xml schemas. Chee-Kai: If implementations create problems, yes, that needs to be surfaced, but if you are talking about different ways to write schemas (because xml schema allows implementations in several different ways), this doesn't seem to me 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. | Gunther: I'm not looking at the options of designing schemas, just to raise issue that current definitions of ndrsc will be an implementation problem (eg. local vs. global, venetian blind, etc). Otherwise implementers of Ubl schemas into their apps will see it's too complicated and they'll ignore ubl which will be a problem. Better if we do this as a group. Chee-Kai: yes, we don't want to alienate people, but if xml schema is a recommendation from W3C and we are making statement that this is too complicated, then it suggests that in general all schemas written this way would have a problem. Gunther: Next week we'll discuss modifying the charter. Gunther: For now, 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 beacuse features are missing, then we write recommendations on this for further features for ubl to use the tools more effectively. Gunther: For now we can write quick-and-dirty for testing/poc, but not develop complicated apps becasue the time is too short. Chee-Kai: Is there a way to quantify this complication you talk about? If this is proposed to the public, there will be questions to say what is complicated. To some maybe complicated, but maybe not to others. Gunther: Normally in future people will be definiting libraries by using ccts stuff - not xml, ccts. Defining dictionay entry names. These are separeted by dashes/points; these must be always unique. But now, it's interesting - you can write tools to generate tag names from dictoinary entry names automatically. Maybe if we can see - oh, that is vey complicated because need to do double-checking, validation - then always I would like to say 'change tag names from global delcared tag names'. It is easy to see how we can generate tag names from d.e.n. That is one issue i'd like ot reaise up; another is that normally you use types to genrate java classes to use object inside of java environment. But now you have globally declared elements. Schedule for Monteal: Weekly meetings, Thursdays, 1-1/2 hours, 7:30 am PDT. 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