The “htx” parts in digital_publishing_workflow_tools with the earlier predecessor automated_digital_publishing comprise the early stages of a system that implements an abstract capability architecture standard (think POSIX) around the notion of small, independent tools/components supporting each other to perform higher-level operations. The goal is to build an Open Hypertext System for document aspects to follow later once the foundation is in place.
Integration can happen by adding a capability implementation or the whole system to an existing application or to call it as an external function/service. Another way would be to register an existing application or capability as the implementation for the system to invoke it, which requires the conformance of the capability implementation with the expected input/output as well as with the expected functional behavior. But there’s no need to integrate on the level of code execution: the system is designed to act on input automatically or user-driven, for which the input needs to either follow a scheme for semantic bootstrapping (think OSI model that establishes meaning with the help of wrapping “containers”), or, if it is from an external source, needs at least declare the identity of its format, so it can be imported/converted.
In practice, the system isn’t ready yet and most capabilities are still missing. For what has been done during the Doug@50 effort, the system can download all posts from a WordPress instance if the WordPress JSON API is enabled (it is per default) and the permalink setting isn’t “Plain” (it is per default, and changing it requires
mod_rewrite on Apache or equivalent) in order to generate a single XHTML page, an EPUB and a PDF for print from it (not very beautiful yet). One precondition for now is that the posts comply with their own format convention, in this case: they have to be well-formed according to XML rules. Some posts on jrnl.global aren’t, so the system and the data on the site remain incompatible.