A plug-in fragment is used to provide additional plug-in functionality to an existing plug-in after it has been installed. Fragments are ideal for shipping features like language or maintenance packs that typically trail the initial products for a few months. Another frequent use of fragments is to deliver OS or windowing system-specific features. When a fragment is detected by the platform and its target plug-in is found, the function in the fragment is "merged" with the original function in the target plug-in. If you query the plug-in registry, you will see the features defined in a fragment as if they were contributed by the original plug-in.
While this merging mechanism is good from a runtime point of view, developers need to view fragments as separate entities while working on them. Fragment development is often done by different teams, on a different schedule, sometimes even on different operating systems from the original plug-in.
PDE provides full support for fragment development. Fragments can be viewed as "limited plug-ins." They have all of the capability of regular plug-ins but have no concept of life-cycle. Fragments have no top-level class with "startup" and "shutdown" methods.
The PDE concept of workspace and external plug-ins turns out to work quite nicely when developing a fragment. You can work on a fragment whose target is an external plug-in. Since external plug-ins cannot be changed inside the workbench, the environment inherently supports the fact that the fragment should be developed without modifying its target plug-in.