Home » SharePoint and XDelivery for DITA Publishing: What to Compare

Documentation platform comparison

SharePoint and XDelivery for DITA Publishing: What to Compare

By Andrew Douglas

August 22, 2025
8:46 pm

Check DITA processingCompare reader journeysTest release ownership

SharePoint can be a useful home for collaboration, controlled files, and internal knowledge. Publishing a DITA documentation collection adds a different set of requirements: resolving maps and references, maintaining product and version context, delivering topic-level navigation, and updating a complete publication reliably.

The important comparison is how much of that workflow your organization must build and maintain. A purpose-built documentation delivery platform such as Bluestream XDelivery may reduce that work, while SharePoint may remain the right place for other enterprise content. Evaluate both against the reader experience and release process you actually need.

Separate file management from DITA publishing

A DITA publication is more than a folder of XML files. Maps organize topics; references and keys connect reusable material; filtering produces variants; and transformation creates the reader-facing output. Uploading the source files to a document library does not by itself perform those operations.

For example, DITA Open Toolkit’s HTML5 transformation generates HTML and a table of contents. An implementation still needs to decide how that output reaches readers, how its assets and links work, and how subsequent releases replace or coexist with it.

SharePoint can participate in that architecture as a source repository, file destination, or entry point to another service. The question is whether your proposed implementation provides the complete DITA publishing and reading workflow, rather than whether it can store an XML or PDF file.

Recognize what SharePoint already provides

A fair comparison should not describe SharePoint as offering only basic search, limited metadata, or no meaningful permissions. Microsoft’s managed metadata documentation describes central term management, controlled vocabularies, and metadata-based navigation and discovery.

Its search-schema documentation explains managed properties, search customization, and permission-aware results. Some refinement settings apply specifically to classic search, so check the experience and configuration used in your tenant rather than assuming every SharePoint interface behaves the same way.

The remaining work is documentation-specific

Determine how a user moves from a search result into the correct manual, recognizes the release, follows a cross-reference, and changes language. Test whether search finds a topic or merely the containing file, and whether inherited DITA metadata survives the publishing route.

These are implementation questions. Existing SharePoint investment, staff expertise, and governance can make a customized approach practical. They do not remove the need to design and support the DITA-specific parts.

Evaluate the hosting and update path

Do not assume that uploading generated HTML will produce a supported documentation website. Confirm how the target SharePoint environment handles HTML, scripts, linked assets, and navigation. Microsoft’s custom-script guidance describes restrictions and security considerations that can affect a proposed approach.

Choose a supported architecture with your SharePoint administrators. Weakening a tenant’s security settings to make a documentation package render should not be the default solution. An external delivery service, supported integration, or different publication format may fit better.

For any route, inspect the update process. If one topic changes, which files must be regenerated? How are deleted topics removed? When does search reflect the release? What happens when an upload fails halfway through? A reliable answer to those questions matters more than a successful one-time demonstration.

Where XDelivery fits

XDelivery is designed around delivery of technical documentation, including DITA and other content formats. Its value should be assessed through the specific documentation workflows it can support for your team.

Bring different technical collections into one experience

A documentation audience may need generated HTML, PDFs, videos, and related files in the same search and navigation journey. Demonstrate ingestion and updating for each format you use, including the behavior of links between collections. A promise of multi-format support is most useful when tested against representative assets.

Apply a shared discovery model

XDelivery’s documented metadata and search capabilities can support filtering across technical collections. Choose a small, consistent set of product, release, language, and document-type values. Ask how source metadata is imported, where delivery-specific metadata is maintained, and what happens when values conflict.

Support readers inside existing workflows

Bluestream describes standalone and integrated delivery options. The relevant test is whether your customer portal or support application can surface the correct content while preserving identity, permissions, and links. Confirm the connector or API work required, rather than assuming that naming an integration means every use case is preconfigured.

Check offline and field-service requirements

The XDelivery field-technician overview describes offline capabilities and an integrated parts catalog with third-party commerce integration. If these matter to your organization, include them in the demonstration: download a relevant collection, use it without a connection, identify an update, and follow the intended parts-information journey.

Capabilities, configuration, licensing, and delivery scope should be confirmed for the proposed solution. They are not a blanket guarantee of deployment speed, lower total cost, or regulatory compliance.

Compare the complete operating cost

A SharePoint license already present in the organization can make the starting cost look attractive. Include the work required for DITA transformation, metadata mapping, reader interfaces, search configuration, testing, and ongoing integration maintenance.

For XDelivery, include licensing or subscription charges, implementation services, migration, identity integration, training, support, and any custom development. Use the same content volume, languages, audiences, and expected traffic for both estimates.

Ask who owns the solution after launch. If the only person who understands a custom publication script leaves, can the team still release a correction? Conversely, if a packaged platform changes its API or hosting arrangement, how will the organization adapt? Procurement should consider maintainability and exit options as well as the initial rollout.

Run a comparable proof of concept

Score what you observe rather than a feature label:

DITA fidelity: keys, reused content, conditional variants, images, and cross-references resolve correctly.
Reader context: the product, version, language, and place in the publication remain visible.
Discovery: realistic queries return useful results with appropriate filters.
Access: an unauthorized reader cannot retrieve restricted content through a page, search result, download, or API.
Release control: a failed update is detected and a previous approved publication can be restored.
Operating effort: ordinary updates can be completed by the intended team with documented support.

SharePoint and XDelivery can also coexist. SharePoint may continue supporting internal collaboration while a dedicated delivery tier serves customer documentation. The right boundary is the one that gives readers a coherent experience and gives the organization a manageable release process.

Frequently asked questions

Can SharePoint store DITA content?

It can participate in storing or managing files, but storage alone does not resolve DITA maps, keys, reused content, or publishing variants. Verify the complete processing and delivery route.

Does SharePoint lack metadata and search refiners?

No. SharePoint has managed metadata and configurable search capabilities. The relevant comparison is how well the proposed configuration supports your technical-documentation tasks.

Do we have to replace SharePoint to use a documentation portal?

Not necessarily. A dedicated delivery service can coexist with enterprise collaboration systems. Define source ownership, identity, links, and publishing responsibilities at the boundary.

Is XDelivery always cheaper or faster to implement?

That cannot be assumed. Compare the full implementation and operating effort using the same scope, and confirm timelines against your content, integration, and governance requirements.

What is the most useful pilot?

Choose content that exposes real complexity: versions, reuse, restrictions, translation, and mixed formats. Test an update and a failure as well as the initial publication.

Contact Us

IN THIS ARTICLE

01Separate file management from DITA publishing
02Recognize what SharePoint already provides
03Evaluate the hosting and update path
04Where XDelivery fits
05Compare the complete operating cost
06Run a comparable proof of concept
07Frequently asked questions

SOURCE LINKS