Sub Content Overview

The File Type Support Framework allows users to create sub-content filters or processors which handle content which is of a different format to the main content. For example, an XML file may contain a CDATA section which in turn contains HTML markup. The main XML filter processes the XML until it hits the CDATA section. It then passes the contents to the CDATA section to the framework and asks it to process this using an appropriate sub-content processor (in this example, an HTML processor)

Handling SubContent in the File Type Support Framework

The File Type Support Framework supports handling of sub-content in the following manner:

The main parser must be able to determine which of its content is to be treated as sub-content. In order to push the sub-content to the framework, it must implement the ISubContentPublisher interface. This interface defines an event named ProcessSubContent which is raised whenever the main parser wishes to pass off subcontent to the File Type Support Framework. The main parser populates the properties of the ProcessSubContentEventArgs and then raises the event. The File Type Support Framework takes the ID of the sub-content processor from the event arguments and uses this to set up this processor to handle the sub-content.

The sub-content processor is a regular filter parser which implements the ISubContentParser interface. Two of its requirements are to be able to handle streams and document fragments. The parser receives the stream containing the sub-content when the File Type Support Framework calls the InitializeSubContentParser method. The parser must simply use this stream to parse the content from. Everything else is set up in the same way as for file-based parsing.

For target regeneration, the framework makes calls to a sub-content writer which builds up the sub-content during these calls. The sub-content writer must implement the ISubContentWriter interface. The framework initially calls the InitializeSubContentWriter method in order to pass in the original sub-content, in case the writer needs this data to reconstruct the generated content. Once all of the sub-content has been built up, the framework calls the GetSubContentStream method in order to retrieve the sub-content stream from the writer. In order for the framework to pass the sub-content back to the main writer for insertion into its output stream, the main writer must implement the ISubContentAware interface. This allows the framework to call the AddSubContent method and pass the sub-content to the main writer.

In order for the framework to be aware of a sub-content processor, it must implement a component builder which specifies which parser and writer to use for the processing of sub-content. The component builder must implement two interfaces, namely, IFileTypeComponentBuilder and ISubContentComponentBuilder. The component builder must implement BuildSubContentExtractor and BuildSubContentGenerator. These methods are similar to the regular BuildFileExtractor and BuildFileGenerator methods, but instead, allow the component builder to specify a specific parser and writer along with additional processors for the sub-content processing. The method BuildFileTypeInformation should also be implemented, however, all other methods may return null. A unique File Type Identifier should also be used for each processor. Please note that File Sniffers are not used by sub-content processors.

The same settings pages may be used for sub-content processor where this makes sense. Usually sub-content processors use a sub-set of the main filter's setting pages with some instances of customized settings pages required.

In order to display the sub-content FileTypeConfiguration Ids in your UI, you must pass in the list of UIs from the settings page to the UI control. You can then populate a dropdown with the Ids and allow the user to select which processor they will use to handle the sub-content from the main filter. Here you can see how the Ids are obtained via SubContentFileTypeConfigurationIds. The selected Id should be stored in a settings object which can be accessed by the main parser and passed along in the ProcessSubContentEventArgs via the ProcessSubContent event call.

Embedded content (or sub-content) is processed by the framework in a sequential manner. First, the main filter processes its content and if it detects any sub-content then raises an event passing in the sub-content. The sub-content parser is then called and consumes all of the sub-content. When this is done, the framework continues with the main parser again. This flow is shown as follows:

This is saved in the SDLXLIFF file as individual file sections as shown above. In Trados Studio, this is presented as:

Note

It is currently not possible to extend a sub-content component builder in the same manner as a filter component builder.

Note

This content may be out-of-date. To check the latest information on this topic, inspect the libraries using the Visual Studio Object Browser.