Alan Conway wrote:
On 01/06/2010 06:52 AM, Robert Godfrey wrote:
2010/1/6 Rafael Schloming<rafa...@redhat.com>

Robert Godfrey wrote:

Overall I think with a bit of work from both the C++ and Java communities
we
can get the brokers to look and behave much more similarly... however we will also need to change the way we work a bit so that when we decide to
add
new features we attempt to discuss and agree before implementing. It will
do
no good to get the brokers temporarily aligned if they immediately begin
to
drift apart again.


I'm just thinking aloud here, but perhaps it would help to gather our
various disparate documentation snippits into a single canonical feature
glossary somewhere in SVN. Ideally in some format that could be easily fed into the documentation, but could also serve as a source for other things such as generating test matrices, and doing feature based coverage analysis.

--Rafael



That sounds like an excellent idea...


Can jrobie's proposed docbook for documentation project provide the right format for this? It's XML so should be possible to generate various types of file. Seems like something we want to be able to inject into the user doc as well.

Possibly, I'm not a docbook expert. Either way I suspect a simple XML file could be trivially transformed into docbook and whatever else we need, e.g. something along the lines of:

<feature name="foo" title="Foo">
  <description>
    Blah blah blah.
  </description>

  <component name="java-broker"/>
  <component name="cpp-broker"/>

  <test ref="pointer-to-test"/>
  ...
</feature>

I'm not sure the extent to which we want to cross reference tests/components/etc against this sort of thing. If that's something we feel would be valuable then I suspect making up a simple XML format and translating to docbook would be the way to go. If on the other hand it's essentially just a documentation-only feature glossary then I'm sure docbook alone would be sufficient.

As long as the format is fairly regular, I'm not particularly fussed either way as it should be straightforward to translate later if necessary.

--Rafael


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Reply via email to