The existing PT design presumes that all strux of a given type are adjacent to another strux of the same type, so you can use very simple leftwards lookups to reconstitute the imported document hierarchy. Fields are our first "non-adjacent" container, which require us to keep track of both the begin and end points explicitly in the piece table. We're getting away without API mods because we're "hiding" that complexity behind PTX_FieldEnd. If, however, we want to generalize the "end strux" handling so we can later use it for other non-adjacent containers in the file format, then we *will* need to widen one or more of these APIs to pass a bit more information. instead of we could do something like ---------- -------------------------- appendStrux(PTX_FieldEnd) endStrux(PTX_Field) insertStrux(pos,PTX_FieldEnd) endStrux(pos,PTX_Field,sdh) Thew idea would be that instead of creating another strux subtype (PFT_Strux, PTX_FieldEnd), we could have another frag type (PFT_StruxEnd, PTX_Field). A change like this would probably simplify the piece table implementation in spots -- especially _getStruxOfTypeFromPosition() -- but I'm not sure it's worth it, at least now. In particular, I believe that to pass enough information to make undo work, we'd also have to widen the PX_ChangeRecord and PL-Listener APIs accordingly, and that sounds like overkill. Of course the final decision here is up to whover does the implementation, but off the cuff I'll stick to my recommendation that we not introduce this level of generality until we know we need it. Paul
