OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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

Tools and Techniques (TT) SC Report

Eve Maler

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.

SC Logistics

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:

Do we have any general platform requirements?

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.

A-Priority Tasks

What should the UBL source form(s) be?

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:

  • A schema for the metadata that we intend to insert into the 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.
  • One or more stylesheets for presentation of the XSD into reviewable and browsable forms (e.g. hyperlinked HTML, UML, elm trees, etc.).

Owner: Arofan.

What should the UBL normative form(s) be?

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

What tools and techniques are needed for analyzing the inputs to the UBL design process, producing analysis artifacts, producing review forms for liaison review, and producing BIE designs?

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.

How should the code for the source form and other auxiliary work outputs be managed?

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.

B-Priority Tasks

What tools and techniques should be used to produce additional outputs from the source form, besides the normative form (if it isn't the same as the source form)?

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).

How should builds be managed?

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

What issue-tracking system should we use for maintenance and updates to the source form?

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

What tool limitations will impose constraints on the schema design process?

Requirements: For example, the CommerceOne VB application does this.

Recommendation: TBD

Deliverables needed: TBD

Owner: TBD

C-Priority Tasks

What tools issues are there regarding versioning?

Requirements: We should defer this until we get feedback from the N&DR SC.

Recommendation: TBD

Deliverables needed: TBD

Owner: TBD

What tools and techniques are needed for regression testing?

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

What tools and techniques are need for ensuring adherence to the schema design rules?

Requirements: For example, the CommerceOne VB application does this.

Recommendation: TBD

Deliverables needed: TBD

Owner: TBD

Examination of Current xCBL Practice

CommerceOne developed their own tools rather than to try to customize other tools. A custom VB application for developing new document types allows dragging and dropping of components, and requires documentation to be added by the business analyst; it constrains results to the document type creation guidelines. This application was eventually planned to be distributed as freeware.

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