Introduction |
![]() ![]() ![]() |
See also: What are Standard Format Markers? In general terms, a markup language is a special notation for identifying the components and structure of an electronic document. It combines extra information about the text together with the text itself. The extra information is what is expressed using markup. Markup can also include information about the intended presentation of the text, or instructions for how a software process should handle the text. A good markup system is easily identified as separate from the text itself.
Standard Format Markers have been used for many years within the Bible translation community as a method for identifying the unique textual elements which exist within an electronic scripture document. SFMs start with a backslash character "\" and end with the next space. Over time many different local "standards" for SFM use were developed, adapted, and used, for supporting the varied requirements of Bible translation and publishing projects around the globe. The divergent use of SFMs led to a variety of problems – most notably the challenges associated with sharing text or related text processing tools among entities, departments, or partner organizations. Separate and ongoing maintenance of duplicated tools and procedures, which were required for managing the flow of the text through its life-cycle, became costly and very difficult to support.
In March 2002 a working group was established within the United Bible Societies with the mandate of "crafting a unified specification for SFM use across 4 UBS areas". Having one SFM standard would provide numerous benefits:
Ideally an SFM standard would have as one of its goals that of marking common scriptural element types, and not formatting (presentation) information. USFM has attempted to "unify" a long history of SFM type scripture markup "standards", some of which were more or less strict in their tolerance for format-oriented markers. The primary focus in USFM development was on unification, not markup creation. What this means is that USFM inherits support for both the positive (and some negative) aspects of pre-existing SFM marker use. The USFM working group did not wish to create an unmanageable conversion task for legacy SFM encoded texts.
Over the course of its development it has become clear that the USFM standard will not likely include and handle markup for all potential (real or perceived) markup needs which a project may require. There are a number of reasons for this, which include:
Since USFM 1.0, requests for additions to the standard have been received and considered by the USFM committee (see Release Notes for some details). The committee has made a choice to specifically exclude new markers submissions that specify formatting from becoming part of USFM. What this means is that the USFM standard is open to the consideration of new markup needs, but closed to allowing new format oriented markup. At times this position has caused some frustration for users who might otherwise be quite satisfied with USFM, but would be greatly assisted by adding markup to their text which is not a part of the standard. Option: The \z namespace As a means of offering a type of solution to the need for occasional local markup additions/extension, the USFM committee has agreed to document a recommended practise.
The USFM committee felt that this was a reasonable approach since applications like The most recent full and draft USFM stylesheet files for use with the Paratext translation editor are always available from
|