Besides the conversion of the content, there is an integration to be considered for the purpose of verification of having tests in the TCK to cover it all.
As explained informally by Gunnar:
{quote}as you know there is a TCK
and there is a "TCK coverage report" which gives us an indication of which parts from the spec are covered in the TCK
"covered" here means there is at least one test method in the TCK which has an annotation such as @SpecSection(1.2.3)
(so if the test itself is bogus, this doesnt help of course)
in addition there is an XML file which contains all the TCK-relevant sections/phrases from the spec
that TCK coverage report generator then takes that XML and checks how many of its contents are reflected in @SpecAssertion annotations in the TCK
and that XML file in turn is generated from the spec DocBook itself - which is why i bring that up
so there is an XSLT sheet which takes specific docbook parts and copies them into that XML file for the TCK report
for that purpose, we used the docbook feature of "roles" to mark specific phrases as "tck-relevant"
so we'd need a similar mechanism for asciidoc, [~sanne]
that all "relevant" spec statements are covered by the TCK
iirc we also had a rendering mode where the rendered doc html highlighted the phrases marked as tck relevant
just some CSS i suppose
that way you could skim over the spec and see whether it lacked any TCK phrases for relevant parts
in a first step I'd check what's the equivalent of "roles" in asciidoc and how we can extract that information to create the TCK file
the actual reporting will not change
it's just the first part of the pipeline I am talking about here
extracition extraction of marked phrases from the spec into that XML file; from there it should continue to work as is
of course we could discuss to stay on DocBook, but I think we all agree that authoring is a pain
especially since the free editor we used to use isn't available anymore.
BTW. another issue with the tool used by hardy for docbook -> asciidoc conversion was that it lost markup such as classname, methodname etc.
would be interesting to see whether we can retain these for the BV spec{quote}
|
|