On Sat, 2005-11-26 at 13:18 -0600, Tommy Reynolds wrote:
Uttered "Paul W. Frields" <stickster(a)gmail.com>,
> - I wonder if it would be wise to have a change to the DTD which offers
> a 'release' in addition to 'version' for a 'revision', such
> <revision date="Sat Nov 25 2005" version="0.1.3"
> would be allowed. The latest release number would be the thing that
> appears in the %release tag. The 'release' element that falls directly
> inside 'rpm-info' would be eliminated. There is always a chance that
> things have to be repackaged because an OMF or .desktop file is updated
> -- or even the spec template -- but not the doc content, which calls for
> a release bump, not a version bump. Is such a thing possible, Tommy?
My thought was that the /rpm-info/release value would represent the
RPM packaging release cycle.
Ah, I see, that makes sense... IOW we would hope that if we do this
right that might never change, right? Sorry, forget that snippet above,
The <revision> components of the
<changelog> would generate both the RPM %changelog and the DocBook
Hm.. would a "role='rpm'" attribute on the
element suffice? I could then just skip that entry when building the
Well, I think having that sort of structure makes sense, in that some
changes will be packaging only, and some changes will be document only.
It probably makes sense for the document revision history to be in the
RPM %changelog but not the other way around. What if we were to use
some of the XSL "if" statements to perform some of that magic, and have
a hierarchy like this:
<details>Some guff here</details>
<date>Sat Nov 26 2005</date>
<name>Paul W. Frields</name>
<email>stickster at gmail</email>
> Just some quick ideas... I'm not really conversant with a
lot of XSLT
> stuff so I may piddle around with this, but not expecting great things
> as a result. ;-)
Neither am I, but if you can help get the prototype SPEC, OMF, et.
al., files right I think I can mangle the XSLT stuff enough to get
I am doing some DTD and XSLish reading... your new additions here have
helped make this a lot easier for me to learn a bit, so thanks for that.
I might play around with what's there, but will try not to break
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/