[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: minutes from last 2 TTSC meetings
Hello, It's come to my attention that Kavi is no longer sending email when I post documents, so here are the minutes from the last two TTSC meetings. -Anne
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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]