Such filters can be used for importing a content.
Of course it's possible to combine it with the service ExportFilter
if export functionality should be available at same implementation too.
It's used to filter a document at loading time.
The target document should be already setted by using another interface
XImporter which is supported by this service too.
Tip:
If same implementation provides the service ExportFilter too,
code must distinguish between filtering into a target document (for import) or
filtering from a source document (for export). This can be recognized by saving
state of used interfaces XExporter or XImporter!
Otherwise it's not clear which action is required here.
support initialization of filter with its own configuration
A filter object must be created by global service FilterFactory.
If filter supports this optional interface, he will be initialized by the factory directly
after creation. The factory will pass follow informations to this new instance:
first item will be a set of configuration data of the filter
provides access to the internal name of this filter
This internal filter name can be used on service FilterFactory
to get further informations about it (e.g. his registration for mime types or extensions etc.)
It's important that returned string is the "internal name" of the filter which must be
unambigous against all other registered filter in current instalation.
Attention!
Supported method setName() sould be ignored or forwarded to the FilterFactory.
It's not allowed to set it directly to the configuration. Because it depends
from real implementation of the FilterFactory if it will be allowed or not!
