FYI. Here are the assumptions I used when working on the fields design earlier this summer: I. Use the same file format for all fields. The arguments can vary as much as needed, but we should use the same attribute name iff the concepts are semantically equivalent. II. Field contents are editable and participate in undo actions. For details on the desired interaction behaviors, see: http://www.abisource.com/mailinglists/abiword-dev/00/June/0233.html III. Although some piece table changes are likely, they shouldn't be that extensive. All knowledge of the semantics of particular fields (and their attributes) should be encapsulated outside the piece table. The piece table's job is just to reliably import/export and handle editing and undo via the various inbound (Document) and outbound (Listener) APIs. IIIa. Undo is the hidden orphan of this design space. Favor solutions which make seamless undo/redo behavior easy to implement reliably. IV. Breaking file format compatibility with the existing FIELD hacks is OK if we have to, so long as we do it before 0.9.0. IVa. If so, it'd be polite to have an easy way to do the conversion. IVb. However, I'm leery of leaving compatibility code in our importers over the long term. I respect Eric Bina's work tremendously, but I don't want to follow his precedent in the word processor world. V. If we can't eventually express *every* field defined in the RTF spec, then our mechanism isn't general enough. Va. It's fine to postpone most of those implementations, though. For example, we'll need to add a bunch of code for style and section editing before we can consider adding TOC support, which sounds entirely out of scope for the 1.0 timeframe. (Unless Bruce decides to quit his day job.) ;-) Vb. However, it would be a Bad Thing to knowingly take a shortcut now which will force us to go through outrageous gyrations (or worse, break file format compatibility) to implement additional fields later. VI. And finally, my favorite design principle always crops up -- KISS. If done right, our generic fields implementation really shouldn't have to be all that complex. Paul
