[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl] Tools and Techniques SC report from 1 November 2001
Title: Tools and Techniques (TT) SC Report
1 November 2001 [corrected in accordance with TC instructions]
This subcommittee has the following members:
Also attending were, on Tuesday morning, Dale McKay, Gunther Stuhec, and Adam Cheyer, and on Thursday morning, Dale McKay, Gunther Stuhec, Mark Crawford, and Bob Glushko.
"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."
We're comfortable saying "tools and techniques" and not getting into the question of Methodologies (with a capital M!).
Our "customer" is the TC, not external developers.
We have dependencies on the NDR SC in that (e.g.) they may need certain schema features to be supported, which will place requirements on our recommended tools.
The subcommittee isn't in charge of developing tools (e.g. scripts), but we might recommend tools that one of our number has developed.
We anticipate being a standing subcommittee, but don't want to meet as frequently as the new TC rules specify after having developed our initial recommendations.
Arofan Gregory has offered to chair this SC, if the TC agrees. [Accepted by the TC.]
Gunther Stuhec and Dale McKay have asked to be added to the TT SC as a voting member, if the TC agrees.[Accepted by the TC.]
The SC has prioritized its tasks in the order shown below. It will attempt to get as much input about tools needs as possible from the Library Content SC today and in the following two weeks, and will produce draft proposals for the A-priority items by the week of November 19. There will be a TT SC teleconference held that week, with future meetings to be scheduled as needed. The SC will report to the TC in good time for Jon Bosak's XML 2001 UBL talk.
The tasks for this SC are divided into A-priority (immediate need), B-priority (can be deferred a bit), and C-priority (has distinct dependencies on previous items).
One topic has been discussed to conclusion:
Recommendation: We think that all non-Internet-based tools should be platform independent (that is, they shouldn't be biased in favor of one platform). Web forms with an XML-creation back end should be used for rationale management and other input tasks as much is as practical.
Requirements: The source form has to have at least as much expressive capability as the normative form.
Recommendation: The source
form should be XSD with special appinfo and documentation
fields inserted into it. It can be edited with common tools (some free, some
available on multiple platforms).
Deliverables needed: We need to develop:
appinfo
and documentation fields, based on input from
the Library Content SC and taking into account the kind of UBL documentation
deliverables we want to produce.Owner: Arofan.
Requirements: Users will need to be able to validate with it, customize it, mix and match components, and author documentation associated with it.
Recommendation: So far we have discussed XSD as the normative form, but it was noted that RELAX NG might be a very useful auxiliary output, if not a (primary or secondary) normative form. TBD
Deliverables needed: TBD
Owner: TBD
Requirements: The CC spreadsheet, xCBL, and the CC-to-xCBL mapping work may need to be encoded and transformed in various ways for optimum analysis. xCBL may need to be subsetted to eliminate non-core material. It might be useful to have available an XSD expression of the CC (this is being worked on in a UN working group) for analysis. Someone producing a proposed design for (e.g.) a purchase order document type needs to convey it somehow to other SC members and liaison groups. This artifact should be machine-processable, but it doesn't strictly need to be in our true source form (though it would be nice); it should ideally be transformable into it in one-way fashion. Designing BIEs will require recording context information somehow. It will also require the ability to search across and find all components in sophisticated ways, based on metadata about them.
Recommendation: It was noted that topic maps might be a good way to allow people to do interesting navigation among the components, and good topic maps could possibly be generated if there is enough metadata present. TBD
Deliverables needed: TBD
Owner: Arofan.
Requirements: This needs to be Internet-based and have access control. We could see this as "code" management (like CVS) or "document" management (like dot-com collaborative work environments). We need to be able to get XML-enabled diffs, but this doesn't have to be Internet-based.
Recommendation: SourceForge might be a possible solution. Norm Walsh's diffmk tool might be useful. We noted that both the DocBook and the RELAX NG TCs use SourceForge to manage their outputs. TBD
Deliverables needed: TBD
Owner: Eve and Dave.
Requirements: This might include mappings, if they can be generated. However, the Planning SC had recommended that this not be a deliverable of the TC.
Recommendation: We want to look into toolsl such as JavaDoc for generating documentation. TBD
Deliverables needed: TBD
Owner: Dave (for the generated documentation question).
Requirements: We know we'll need various sequences of validation and transformation. Our test suite of sample instances will need to be validated. Before changes are committed, the test suite will have to be run.
Recommendation:
We might be able to use make for now. TBD
Deliverables needed: TBD
Owner: TBD
Requirements: This needs to be Internet-based and have access control (so that the public can read the issues, but not control their disposition).
Recommendation: BugZilla might be an option. TBD
Deliverables needed: TBD
Owner: TBD
Requirements: For example, the CommerceOne VB application does this.
Recommendation: TBD
Deliverables needed: TBD
Owner: TBD
Requirements: We should defer this until we get feedback from the N&DR SC.
Recommendation: TBD
Deliverables needed: TBD
Owner: TBD
Requirements: We will need to have a suite of test instances and be able to validate schema changes against them.
Recommendation: TBD
Deliverables needed: TBD
Owner: TBD
Requirements: For example, the CommerceOne VB application does this.
Recommendation: TBD
Deliverables needed: TBD
Owner: TBD
The source form produced is a proprietary XML format that is fairly specific to the GUI offered by the tool, but the normative form is SOX that is generated from the source form. DTD and XSD forms and documentation were generated from the RSF. Having the tools interface meant that editing the source form missed out on some of the desired constraints. Having the source and normative form separate means that it isn't possible to edit the normative form in order to make revisions (without the provision of round-tripping). The source form is optimized for the needs of the VB application, but there was no other reason to have the source form be different from SOX.
CommerceOne decided that Xerces and Xalan are the de facto standards for coverage of features. The quality of XSD development environments really isn't there yet.
-- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC