Real-time web publishing of DITA content

[dwmai...@gmail.com]

Hi,

I'm interested in publishing web content from DITA source in real-time. This would allow me to author all of my content in DITA and then render that to a localized, relevant version on page request. I don't mean to build the web version and serve static HTML through apache. I actually had in mind that the document would be rendered at the time of request.

Is anyone using DITA-OT to publish web content in real-time. If so, is your approach documented?

Thanks,

Daniel

[Jarno Elovirta]

Hi

Out of curiosity, what are your reasons for not wanting to create static pages? While you could use OT to render on-demand, it's not optimized for it; Ant doesn't work particularly well with processor pools. Do you use conrefs, or even keyrefs if your documents are part of a map?

J

--
You received this message because you are subscribed to the Google Groups "DITA-OT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dita-ot-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael Hayden]

DITA-OT by itself really isn't designed for this. Many of its features (e.g., verifying cross-references, building the ToC and index, packaging the deliverable) are oriented toward processing the entire documentation set. You might be better off with a plain old wiki (if you want it for free) or a DITA-based CMS (if you're willing to spend some money).

-Michael

[dwmai...@gmail.com]

We were hoping to maintain all content in DITA and render that in real-time on our website, rather than having a build and replication process for content. We would be using translations, references and other DITA features.

[dwmai...@gmail.com]

We have been looking at some of the commercial DITA CMS solutions. That's a good suggestion.

[dwmai...@gmail.com]

Is anyone on this list aware of a project that would use DITA OT but add a pre-caching mechanism? For example, if all DITA documents could be loaded into memory so that they were in RAM before compiling, that may be enough to get the real-time performance I need.

Has anyone tried this?

Daniel

[Eliot Kimber]

In the general case, it is not really practical, or at least not easy, to do real-time delivery of DITA content, for the reasons given: there is too much preprocessing required and too many potential dependencies among topics. In essence, you'd have to track all the dependencies so that you both knew what other maps and topics were affected by any change to given map or topic in the information set. In the worst case, a change to one topic or map causes all other topics and maps to change (for example, a change to a keydef's link text that is referenced by every topic in the set or a change to a conref target used everywhere (product name, release number, etc.). This is computationally possible but clearly difficult to implement, at least with the current set of commonly-available tools. 

But the bigger question is why? What value do you get from this sort of dynamic delivery over periodic regeneration of files?

If you want to minimize updates to your Web site, you could publish to a git repository and then use git to tell you what's actually changed and then use git to push the changes to the Web site. That would be much easier to implement.

I can imagine a system that stages resolved DITA source to an intermediate repository from which HTML is then generated on demand. The FASB does something like this with the codified GAAP content, which is authored in DITA and then published to the Web out of an XML repository, where the repository has pre-digested XML generated from the base source DITA. But the GAAP content changes fairly infrequently, so the reprocessing of the source into the delivery repository is not happening constantly (as far as I know).

If the requirement is to be able to get browse-time dynamic display of conditional content (that is, applying DITA filtering in the browser or in the Web server), that can be done by deferring filtering and pushing conditional details into the generated HTML (e.g., as @class values on the generated HTML elements).

Cheers,

Eliot

--

You received this message because you are subscribed to the Google Groups "DITA-OT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dita-ot-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Eliot Kimber

[San Geoff]

I was about to ask about the same thing but kind of knew the answer. The pre-processing, rel-linking, conrefing, etc.… would be very hard to maintain based on a file by file change.

From my experience with build errors, every file seems to be processed and parsed many times throughout the DITA-OT; one bad file can cause many errors. I can see and understand thought, with all the ant stages in the toolkit and XSL document() calls. 

I was also wondering if processing of large document sets could possibly be speed up by using something like exist-db for the xsl document() calls between some ant stages. That way xml documents don’t have to be reparsed many times (especially for conref source common text documents).

How efficiently does the toolkit use large amounts of RAM?  It seems like the ant tasks of processing each XML along the various ant stages don’t lend itself very well additional RAM. Is there any benefit to giving JAVA the Toolkit 700M vs 3GB? Could the toolkit possibly store the parsed document objects in memory between the ant target tasks, possibly using that cached object in a later ant task? I actually tried implementing something like that back while back, writing my own JAVA XSLT processor class but then realized it would only be caching the XSL which is only parsed once anyway.

[Jarno Elovirta]

Hi,

I’ve been experimenting with and planning something like this and may implement it to DITA-OT 2.x. Basically the problem is that our existing plug-ins expect to be able to read topics from temporary files. Thus, if we just kept everything in memory, custom plug-ins fail when they tried to modify the files between preprocessing steps. For DITA-OT 2.0 we’re already started to move away from built-in Ant tasks and started to use Ant as process configuration only. This way, we could keep all the files in memory and serialize to disk when requested. Since NP (new preprocess) is new and doesn’t have an existing user base, it could be made less extendable via Ant and cache parsed XML.

I’ll try to reply with more detail to dita-...@googlegroups.com

J

[Michael Hayden]

What might that do to the system requirements for DITA-OT? My company is a bit tight with computing resources, so my DITA build server is just one VM among many, and builds are slow as they are.

-Michael

[Jarno Elovirta]

I would expect to see a reduction in processing time and increase in memory consumption, but without an implementation to measure it's just a guess. In some cases you can reduce processing time with the current OT version by changing the configuration a bit. For example, converting the DITA spec will be more than twice as fast if you just reverse the order of keyref and conref processing.

J

--