|
Sort Order:
This is tricky because you would have to infer a lot of semantics to get Docbook out of wiki markup. Wiki-markup is decidedly presentational, which means that we can transform it quite effectively into other presentational markups (PDF, non-strict HTML), but not so effectively into semantic markup. You'd really end up with the equivalent of the HTML transformation, just using docbook tags. Would people consider this useful? As a workaround, you can pull out the (isolated) HTML content of a page using XML-RPC or SOAP, then run it through Tidy to convert it to XHTML? The work around should be working. However, i'd like to retrieve some kind of XML directly, for example to generate a static Website (as Ted suggested) or PDF documentation. Hey Nick, "... the current XML export seems to preserve the wiki markup ..." (quote from Teds post) What we would like to have is the content as Docbook, Xdoc or the like to transform it to other formats. That's why the XML-Export is not exactly what i'm are looking for. I agree that standardization of content export to docbook can be a very usefull feature. Confluence misses flexibility in the way content can be exported and presented in other formats. With support for the docbook format, it would become possible to distribute content through different channels (Eclipse help, Windows help, company specific html/pdf, ...). Hi Thomas, there is a comment somewhere else by an Atlassian employee saying that a docbook export functionality would require each macro to support docbook. Therefore docbook would never be supported. I think this is a valid point, although i don't like that either. The only thing i can think of is to convert the HTML output to Docbook... Any more news on this one. We use confluence for a documentation, but are now producing Eclipse apps, so we'd like to export it and create an Eclipse plugin. Many even free wikis has option export to docbook ( for example MoinMoin), this is extremely useful feature. Is there a separate issue for export to DITA XML that we could vote for? Considering how wide-spread this standard now is, this would be extremely useful to many organizations. Because Confluence does not provide the outputs that we are required to produce, we are currently maintaining our source in DITA and then publishing to Confluence markup as one of our outputs. But we really need a round-robin model to be able to run a truly effective collaborative information-development environment using Confluence (admittedly, the potential loss of semantic markup in the DITA XML source somehow needs to be addressed.). The idea we've had is to use the SOAP api to pull docbook (when implemnted This would be a real timesaver. Does JIRA have an API for parsing the Wiki content? I would also be ok having something locally that pulls down the Wiki content and then takes it apart itself in order to turn it into DocBook. You may want to have a look at http://www.scrollyourwiki.com I'm interested to know if anyone has used this plugin mentioned above: http://www.scrollyourwiki.com We believe this functionality would be best served as a plugin rather than supporting this feature natively. If you're interested to know how we decide on which features to implement, please read this: Scroll 1.0 has been released. See the release notes at: and the plugin page at: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Open
Major
Docbook Export
) in our Maven builds. All our documentation would then be pulled from Confluence on release or snapshot and a maven web site would then be created.
Static content export in XML or XHTML or Simplified DocBook
We too would like to export the content of spaces in a rich format so that it can be utilized by another system. For example, Maven, Cocoon, or the Ant XLST task.
The current XML export seems to preserve the wiki markup, whereas we would like the markup mapped to XHTML or Simplified DocBook.
One use case is high-volume sites, such as apache.org, that can't afford to use dynamic content for the primary website. It would be great to be able to author a site with Confluence, and then export and transform it.
Another use case is authoring text books via Confluence and then presenting the publisher with XML or RFT.
The usages imply that the Confluence look-and-feel would not be reflected in the export. Only content that could be incorporated in another site though XLST.
-Ted.