Myrna van Lunteren wrote:
On 6/16/07, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
This highlights a problem with the release notes process. The input is
HTML but they are then processed with an XML tool. Since HTML is not XML
we will hit this problem with many release notes. Any change folks make
to a release note has the potential to break the generation, even if
they are using valid HTML as expected.
Dan.
I realized there's another issue - what to do when we have another
release candidate? Something to think about in the next 3 weeks.
Myrna
Hi Myrna,
I have scrubbed a lot of release notes, and at this point the release
note generator runs from start to finish for me. I've added some more
defensive logic to the release note generator so that it reports notes
which have improperly formatted summaries--rather than just dying. I
will check this into main and into the branch.
A couple improvements come to mind:
1) We could extract the release-note-reader out of the generator so that
it can be run as a standalone tool. People could use this tool to verify
that their release notes will be digestible by the generator.
2) The error reporting in the generator could be improved: The generator
should collect up a list of all the improperly formatted notes and print
them all out. Right now the generator fails fast and finding the broken
notes is a slow, iterative process.
We should talk more about whether xml or html is the right markup for
the release notes. People will want to sanity check their notes in a
browser. I don't know if most of the popular browsers will display the
xml properly. I'm afraid that if a browser displays the file as html
(even though the file says it's xml), then the browser will switch into
the forgiving mode which allows unbalanced tags and is not
case-sensitive, etc.. In any event, I think that the lint tool described
in (1) will be useful.
Regards,
-Rick
