On Fri, 2005-12-30 at 07:39 -0600, Tommy Reynolds wrote: > Uttered "Paul W. Frields" <stickster@xxxxxxxxx>, spake thus: > > > I had an interesting thought about this, which is that rather than > > having a "version" and "release" attribute, only one of which is > > applicable for each type of revision, why not use a single "revnumber" > > attribute? For docs, this would be a version change, and for new > > package rolls it would be a release change. The latest version for the > > doc and the RPM would always be the "revnumber" attribute of the topmost > > role="doc" revision, and the RPM's release would always be the > > "revnumber" attribute of the topmost role="rpm" revision. > > Which ever is easier to parse. > > Personally, I prefer the two-attribute approach because that seems > more parallel to the actual update process: just change the version > and release, similar to what would be done to manually construct the > SPEC file. The 'role="rpm"' seems a bit artificial to me; perhaps > it's just NIH syndrome. This seems counter-intuitive to me, since documents have a version, not a release -- any document change means a version change (or it should if the editor is doing his job). Meanwhile, RPMs have a release, and the version is tied to the document source inside. The RPM may change versions, but only in conjunction with a document source change. And documents may change versions several times without any release, as they are progressively edited -- especially now that we have the webtest host where drafts are rolled during the work-in-progress. This might be just the occasion to move out of the attribute space and into the subelement space, thus: <revision role="doc" date="2005-12-31"> <author worker="me"/> <revnumber dim="version">0.15</revnumber> <details>Style changes</details> </revision> <revision role="rpm" date="Sat Dec 31 2005"> <author worker="stickster"/> <revnumber dim="release">1</revnumber> <details>Update to 0.15</details> </revision> But frankly, that doesn't get easier to parse for people, which I was under the impression was the whole point behind XML and DTDs. Plus it leaves wiggle room for valid but erroneous entries. We might be well-served by making the DTD do the work for us: <docrevision date="2005-12-31" version="0.15"> <author worker="me"/> <details>Style changes</details> </docrevision> <pkgrevision date="Sat Dec 31 2005" release="1"> <author worker="me"/> <details>Update to 0.15</details> </pkgrevision> This may be a case where it's good to sacrifice compactness on the altar of comprehensibility. > > The only possible issue I see in the commit you made to rpm-info.dtd > > this evening is in requiring copyright holders to be workers. For > > example, Red Hat, Inc. and the Fedora Foundation won't fit that type of > > element, although one or both of them will certainly be copyright > > holders on several of our works. If we're not going to keep it as > > PCDATA, perhaps using subelements (worker|corp) might work. I think the > > KISS method, though, might dictate punting this one. > > Oops, I forgot about corporate ownership. OK, I'll revert it. > /me updates CVS > Done! Saw this, thanks. For some reason I'm getting your mail to the list really late, which is why my response is so delayed in real time. -- 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/
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
