Authoring and composition are separate Arbortext migration decisions

Inventory the behavior behind each asset

Start with a source package and the publication it produced. A directory listing is not enough: it shows what exists but not which behavior the team depends on. Pair each asset with its purpose and an owner who can explain whether that behavior still matters.

• Collect representative content with its schemas or DTDs, catalogs and entities.
• Collect graphics and fonts with the permissions needed for evaluation.
• Include editing frameworks and scripts, noting local rules or identifier handling.
• Include transforms and publishing assets with a reference PDF and its build configuration.

Choose content that exposes difficult behavior rather than only clean pages. Useful cases include long tables with repeated headers, references across modules and unusual page sequences. Add multilingual material where it belongs in the delivery scope. Record missing dependencies before estimating reuse.

Test the editing work against the required issue

The authoring assessment starts with the program's required S1000D issue and local business rules. We propose a task-based demonstration: create a module, insert a reference and select controlled values. Then review a change and validate the result. Record where the target framework supports the workflow and where configuration or development remains.

Oxygen documents schema validation for specified S1000D issues and data module PDF/HTML publishing in its framework add-on. Those capabilities provide a starting point for evaluation, not evidence that every program workflow is covered. Check the documented issue coverage and software prerequisites against the proposed installation. Oxygen S1000D framework

Keep module editing distinct from publication assembly and CSDB exchange. For the scoped sample, identify who supplies identifiers and how references are resolved. Demonstrate any commissioned repository handoff rather than treating a successful editor validation as proof of integration.

Assess output behavior independently of the editor

Map each agreed output behavior to the proposed transform and formatting engine. Classify it as reusable, adaptable or needing implementation. Include font handling and extensions in that assessment; do not estimate the work from stylesheet filenames alone.

PTC states that XSL-FO export needs a .style stylesheet configured for that engine. It also warns that exported XSL may not work in other XSL-FO applications and does not support that use. An export is therefore not proof that the existing publication will render unchanged in another formatter. PTC stylesheet export

Antenna House documents multilingual composition functions, including Arabic direction and mixed scripts. Use those documented capabilities to choose relevant test cases, then render the actual source with the intended fonts and settings. A capability description does not settle whether a particular page meets the delivery agreement. Antenna House multilingual functions

Agree what a meaningful PDF difference looks like

Define the comparison method before implementation. We recommend separate review categories for content correctness and appearance. A changed line break may be acceptable; a missing note or incorrect reference is a different kind of finding. Let the publication approver agree those distinctions before reviewers begin.

• Check content completeness, numbering and reference targets.
• Review table continuation, graphic placement and selected page layouts.
• Record accepted differences separately from defects that block acceptance.

Retain the source revision and build configuration with each result. Record the fonts, transforms and formatter settings so a later run can be compared on known terms. Keep the findings and their disposition with the sample instead of leaving acceptance decisions in email.

The sample becomes a production decision package

For each commissioned workstream, we scope an implemented sample with its configuration and agreed acceptance cases. The handover package includes an asset assessment and a behavior mapping. It also identifies unresolved dependencies and the work proposed for production.

Before cutover, we recommend changing the sample source and running it through the commissioned workflow again. That revision test distinguishes a repeatable process from a polished static result. Reuse the accepted comparison cases after framework or stylesheet changes to look for regressions.

Use the findings to plan content preparation and implementation work. Include author training, operating instructions and parallel output review in the production scope where needed. Keep the existing route available until the agreed acceptance cases pass and the responsible owner approves the change.

Qualification rests on the scoped demonstration

Dakota is listed among Oxygen XML consulting partners under training and consulting. That listing supports our role in framework assessment; it does not establish compatibility with a specific program or prove a publishing migration. Oxygen consulting partners The implemented sample and revision evidence provide the basis for that decision.

Bring a real source package, its required output and the person who accepts delivery to the scoping workshop.

Sources

• S1000D Framework add-on — Syncro Soft / Oxygen, publication date not stated.
• Exporting Stylesheets — PTC, publication date not stated.
• Antenna House Formatter multilingual functions — Antenna House, publication date not stated.
• Oxygen XML partners — Syncro Soft / Oxygen, publication date not stated.