4. The publishing operation

Publishing puts a Technical Committee's approved Work Product on the OASIS documents site as a permanent, citable record. This chapter follows one publication from the moment a request arrives to the moment the audit record is filed. Staff perform every task in it. The TC's part is to approve the document and deliver the package. The TC is never asked to operate the publishing chain, touch the internal repositories, or run a deploy. The one thing a TC may do itself is run the package against the acceptance criteria, published for exactly that purpose and covered in 4.3.

The operation has five stages, and they are sequential:

1. intake
2. preparation and the acceptance criteria
3. the repository chain
4. deploy
5. verification

None of them is optional, including the fifth, verification.

#4.1 What publishing is and why the URLs are permanent

A published document has its own address and never moves from it. Published artifacts are immutable at their stage-specific URL, and a correction requires a new stage rather than an edit in place. Each stage publishes into its own stage directory under the version directory: the stage path is the citable, immutable reference for that stage, and the version directory carries a latest-stage copy of the source, the HTML and the PDF that moves forward as new stages publish. Policy requires the document itself to present This stage, Previous stage where applicable, and Latest stage URIs as display metadata (Naming Directives section 6.2, policy:template_cover_uris), so the addresses are not only where the file sits, they are printed inside it.

Three formats are mandatory, not three formats OASIS happens to produce. TC Process section 2.2.2 requires that all approved versions of OASIS Deliverables be published in three formats:

• editable source
• HTML or XHTML
• PDF

The authoritative source is preserved verbatim at the canonical URL alongside the renderings, and the HTML and PDF are byte-deterministic from the same source on the same toolchain version. That toolchain is the publisher-toolkit (github.com/OASIS-Docs/publisher-toolkit), which consumers pin by release SHA, so the same toolchain version is a specific commit rather than a label.

Case is significant throughout. A directory must not contain two or more names, whether filenames or directory names, that differ only in case (Naming Directives section 4), and a stage abbreviation with its revision number must be used in lower case as a discrete path component in the document identifier, the document URI and the principal document filenames (Naming Directives section 5.2). Only current stage suffixes appear on a new publication: wd, csd, cnd, cs, cn, os and errata. The os stage never carries a revision number. The suffixes csprd, cnprd and cos were removed by Naming Directives v1.7 effective 2 January 2024 and survive only in older published trees; a document entering public review keeps its stage name, so a Committee Specification Draft in review is still csd.

A defect in the published version becomes a permanent part of the record. Any one of these is a defect in a record that other documents cite:

• a broken link
• a wrong date in a citation block
• a file published under the wrong case

That is why the operation ends in verification and an audit record rather than at the moment the file reaches the server.

#4.2 Intake: how a publication request arrives

A publication starts with the TC's request to TC Administration, and the package may arrive in whatever form the TC produces: fully rendered final artifacts, or authoritative source for the pipeline or staff to render. TCs author in Markdown, Word, DocBook or XML, LaTeX and ODT among others. Whatever the intake form, the published result must conform to the same rules, because the bar is the output rather than the input.

Who renders follows from the format:

TC editors deliver through the TC document portal or by email. Staff move the delivered package into the internal repositories, and a TC is never instructed to upload to them; the requester needs no repository access at any point. The attachment record on the request tracker (OASIS runs Atlassian Jira; project key TCADMIN, at https://issues.oasis-open.org, behind a login) shows this side of the operation as data: working-draft markdown sources, a Word-track source, the approving minutes evidencing the vote, and, on one ticket, the Board-approved template handed back to a TC that asked for it. A request that comes through the public Gravity Forms request form writes into the request tracker as a service account and opens a TCADMIN ticket.

Before touching the package, staff confirm five things:

1. the authoritative source
2. the document date the TC wants stamped on the publication
3. the stage
4. the spec short name used in filenames
5. every companion artifact the document cites

The document date often differs from the publication date, and the TC's call wins. A cited companion artifact that does not publish at the cited URL makes the citation block return not-found, which is why the list is confirmed at intake rather than discovered at verification. The ticket that carries the request is covered in chapter 9.

#4.3 Package preparation and the acceptance criteria

Preparation applies the TC's approved edits and brings the package to the house standard: the date in the document heading matching the TC-declared date, real This-stage and Latest-stage URL blocks in place of placeholder text, a citation block whose date matches the header and whose latest-stage URL carries no stage segment, no format tags on the version links, no double slash in an image path, no horizontal rule between the logo and the title, and no editor's notes or draft residue. Most of these items are part of the acceptance criteria, and every one traces to a real correction round in the published corpus.

The prepared package then goes through the acceptance criteria, the executable form of the publication rules. As of 22 July 2026 they run 165 individual rules across 55 classes. The set grows by design, and the inventory is asserted from the code, so the current figure is re-derived with --list-checks rather than quoted from this page. Exit code zero means the package is publishable. A non-zero exit lists the blockers that must be cleared before the package moves forward. OASIS runs the package against the acceptance criteria before anything is committed, so the known regression classes are caught before publication.

The acceptance criteria are track-aware. The full output and package suites run on every package regardless of how it was authored, and source-format rules are add-ons applied to whatever the package carries:

Repackaging or re-rendering is never suggested across tracks. Render class is judged against the TC's own publication precedent, and that precedent governs render fidelity only, never naming or policy.

The same acceptance criteria are designed to run on the TC's side. The TC runs them in its own build before the vote, and TC Administration re-runs them identically at intake, so a green run on the committee's side predicts acceptance without ever substituting for it. After the package clears the acceptance criteria, the publication emits both a machine-readable manifest and a Work Product Manifest File staff record carrying the bibliographic block, the archive listing with checksums, and digests. Both deploy with the package.

#4.4 The repository chain: the repo is the source of truth

The repository, not the local staging tree, is the source of truth for what gets deployed. Using the repository is a mandatory precondition for every publication, including Word-authored specifications, which skip the markdown rendering steps but not the repository. Immediately before any deploy, staff prove that each artifact about to be deployed is present at the pushed commit and byte-identical to it. This exists because a package can be built correctly and synced straight to the servers, leaving no source of truth behind and nothing to audit against.

A new internal publishing repository is created private, before any content is in it. Making it visible is a later and separate decision.

For a markdown publication the render chain runs four workflow steps in sequence against the same publication path and document date, each waiting on the previous to finish. Any change to the source or the stylesheet re-runs all four, because the PDF and the archive must always reflect the current source. A partial re-run is how a PDF ends up rendered from an older draft than the HTML beside it.

Promoting an approved OASIS Standard from an already-published Committee Specification is a stage promotion rather than a rebuild. There is no markdown chain:

1. the TC editor produces the stage-converted authoritative source
2. staff repoint the version directory's latest-stage links from the old stage to the new one
3. the new version-directory listing is diffed against the previous version's listing so that every difference is either justified or removed

On the PKCS#11 v3.2 promotion of 8 July 2026 the diff caught directories left at the top of the version directory by an earlier stage's publish, which the mature previous-version layout does not carry.

#4.5 Deploy and the cache path

Deploy is a manual fan-out to four layers, done in order, every time, together serving https://docs.oasis-open.org:

1. the docs origin box
2. then AWS S3 as the object store
3. then AWS CloudFront as the content delivery network
4. then Cloudflare as the domain and cache layer

The rendered package is copied to the origin box and synced to the object store behind the content delivery network, then the delivery network distribution is invalidated and the domain and cache layer above it is purged by path prefix. The publisher's two deploy steps that once automated part of this chain are no longer used, so the fan-out is done by hand. Cache layers are refreshed on every publication so the public URL serves the new version within minutes, which is a documented commitment to the TC.

Every published file is stamped to the publication date at 17:00 UTC, the OASIS convention, rather than to its actual modification time. Directory index files are generated for every level of the published tree and deployed to the origin and the object store; they are deliberately not tracked in the publishing repository, so a repository pull never overwrites the deployed indexes.

A re-deploy of an already-published tree needs force rather than sync. A plain sync can skip a file whose byte size did not change even though its content did, so index files and manifests are force-copied on a re-deploy. Those are exactly the files that change content without changing length, and because every file carries the same fixed timestamp, a sync sees no reason to upload them.

The publication origin is case-sensitive and no case-insensitive fallback exists anywhere in the delivery path, so any case mismatch between a citation and the deployed key returns not-found. DMLex v1.0 was deployed under an upper-case stage directory while the specification's own canonical links used the lower-case form, and every in-document link failed. Lower case is canonical for stage directories and stage filename suffixes. Where both cases must resolve, the fix is an additive alias: the existing key is never renamed or removed, because removing it breaks anyone already citing that form, and the directory index advertises the lower-case name only. On any case bug, enumerate the whole matrix of directory case against filename case against file type and fix it in one pass.

#4.6 Post-publish verification and the audit record

A publication is not done when the files reach the server. Every publication ends in a three-turn loop:

1. staff review their own work and deploy
2. two independent reviewers then examine the same live state
3. their findings are reconciled, with any defects fixed and confirmed again

One reviewer is mechanical and one is adversarial, and disagreement between them is treated as a signal to investigate. Verification runs against the live site, never against the operator's intent.

The canonical URL set for a standard markdown publication is the four directory levels, the source, HTML, PDF and archive files, every cited schema and image, and the three latest-stage pointers. That comes to thirteen addresses for a package citing two companion artifacts, and more for a package citing more, so the set is enumerated from the package rather than assumed. Every one must return success before the requester is told the publication is live. Links are crawled rather than sampled: every in-document link and every image, object and embed reference is extracted from the rendered HTML and fetched, under every serving context the HTML is reachable from, because relative references resolve differently per context. A cited diagram in one published specification returned not-found for 14 months because an earlier sweep covered links only and not image references.

The publication event itself is then audited against the fifteen mandatory criteria in the canonical registry, each requiring recorded evidence. All fifteen:

1. byte identity between the live site and the pushed repository state
2. any live-versus-repository difference diffed and classified
3. render class against the TC's own precedent
4. front matter against the live roster, the companion document and the ticket
5. stage name under the current naming rules with no revision collision
6. the directory index chain
7. the archive and its manifest byte-identical with no stray members
8. the Invitation to Comment delivered to the all-members community and verified at its destination
9. the post live on the TC's own community
10. the post live on the TC's public comment facility community
11. the discoverability of a public review on the public feed
12. the website news post live where the stage warrants one
13. the ticket carrying the complete verified-link record
14. an independent adversarial verifier briefed to refute the publication
15. a human comparing the live cover page and directory listings against what was published

A criterion that does not apply to a given stage is recorded not-applicable with a reason, so every criterion has a recorded outcome.

Every publication produces two distinct reports:

• The publication audit report records each criterion as pass or fail with evidence.
• The validation report itemizes every individual acceptance criterion with the value pulled from the package and the value it was read against.

Each ships as a machine-readable record, markdown, and a rendered document, all committed to the TC's audit directory in the repository, and both rendered documents are attached to the ticket the TC opened. This is visible in the ticket record rather than only in the rule. Each of these tickets carries exactly that pair:

The reports are named <spec>-<version>-<stage>-publication-audit-<date>.pdf and <spec>-<version>-<stage>-pub-check-validation-<date>.pdf. Chapter 9 covers what the two reports contain and how the verdict is computed.

#4.7 Timing: what is committed, what is observed

No fixed service-level turnaround from intake to live is committed anywhere. The internal work sets the floor: the render chain runs its steps in sequence, and the deploy waits on the cache invalidation completing before verification begins. An absent commitment is not the same as an absent record, and the two have been treated as the same thing before now.

The record exists in the request tracker.

Across the 24 months to 22 July 2026, 113 genuine requests were resolved with a median of 7.2 days from raise to resolution. Of those, 82 were publication, review or ballot requests, resolved at a median of 10.8 days with a range from same-day to 181 days. The query behind the figure is every TCADMIN ticket created since 22 July 2024 with a resolution date, which returns 133 resolved tickets in total.

The method has three limits, and the figures mislead without them:

1. The 20 tickets resolved Invalid are spam submissions and are excluded from the 113, which is why they are reported separately; they resolve at a median of 27.7 days and would inflate the headline number if folded in.
2. The resolution date records when the ticket was closed, not when the TC received the result, so the figure measures the closing of a record rather than the delivery of a service.
3. Several requests resolve in 0.0 days because the ticket was opened on behalf of the requester after the work was already done, which pulls the median down.

This is a record-keeping measure, not a service-level measure, and it should be quoted that way or not at all.

Two operational consequences follow:

• A re-publication triggered by a TC's post-publish edits re-runs the full chain and the full deploy rather than a partial update, so a late correction costs the same as the original publication.
• Because published files always carry the publication date at 17:00 UTC rather than the wall-clock deploy time, the timestamps on the site cannot be used to reconstruct how long anything took; the ticket and the work tracker are the only timing record, and chapter 9 covers what they can and cannot answer.