What's changed

Stilo makes every effort to ensure that new versions of OmniMark are backward compatible with programs written for previous versions. However, compelling design considerations sometimes make it necessary to change the language in a way that is not backward compatible with all existing programs. The following is a list of all such changes made since OmniMark 2.0, together with suggestions for making affected programs work with the current version of OmniMark.

OmniMark 10.1.0

The -nocount command-line option is no longer honoured for compile-time errors.

If #current-input occurred inside a process, process-end or a process-start rule, and outside any input scope, OmniMark used to compile the program but throw at run-time. This error is now caught at compile-time.

The built-in #markup-parser stream is now unattached in the element domain of every parse, including the nested ones.

The default value of the parsing argument of the command-line function in the omprocess library has been changed to be platform-dependent: the default is false on Windows-based systems, and true otherwise.

OmniMark 10.0.0

OmniMark 10.0.0 ships with a built-in module that implements some features of the OmniMark language. This built-in module is installed automatically, in the same location as other modules shipped with OmniMark; furthermore the built-in module is imported automatically into user code. If the built-in module cannot be found, a warning is emitted and this functionality is disabled.

If the functionality of the built-in module clashes with identifiers in your existing program, contact technical support.

What's changed in the OmniMark 10.0.0 compiler

Unexported record types and types exported as opaque now preserve their relationships with other types even outside their declaration module. This change allows more programs to compile. It may also cause a previously valid program module to stop compiling if it defines an overloaded function or conversion-function on two types that were previously considered unrelated. This change is unlikely to affect users. If you encounter any problem, contact technical support.

The compiler accepted invalid type variances on the return types and arguments of dynamic and overriding functions. This is contrary to the specification, and is no longer allowed. This change is unlikely to affect users.

What's changed in the OmniMark 10.0.0 runtime

The content-start and content-end patterns in translate rules were respectively succeeding at the beginning and end of markup comments and some marked section. This was contrary to the language specification and the user documentation. Beginning with version 10.0.0 of OmniMark, these patterns succeed only at the beginning and end of element content. This change will only affect programs that use these patterns in translate rules and contain one of the rules markup-comment, marked-section ignore, marked-section cdata, or marked-section rcdata in the same module.

The definition of the occurrence operator has been changed: instead of comparing the names of consecutive elements, now it compares their declarations. Since SGML and XML DTDs map each element name to a single element declaration, this change has no impact on legacy programs that do not use do markup-parse.

What's changed in the OmniMark 10.0.0 libraries

The OMOCI library has been deprecated, and is only provided on AIX 5.3 and HP-UX B.11.31; users should consider transitioning their programs to use the omdb library instead.

Stilo no longer provides support for Oracle connectivity for Oracle 8i database clients, nor for Oracle connectivity for Oracle 9i database clients on platforms other than SunOS 5.8.

The library omsedna is no longer supported, and no longer shipped with OmniMark.

OmniMark 9.1.0

#current-input was accessible in the initialiser of a global shelf declaration. This is no longer allowed.

OmniMark 9.0.2

A warning is now emitted if the keyword optional is encountered as a herald on an argument in a catch declaration. This use of the keyword optional is deprecated and may be removed from a future version of the language.

The omutf-8 library has been modified to reject overlong sequences by default, as prescribed by the Unicode 5.0 standard. Consult the library documentation on how to recover the old behaviour.

OmniMark 9.0.1

The escape declaration is deprecated, and a warning is emitted when it is encountered. The escape declaration may be removed from the language at a future date.

The external exception thrown by the OMPROCESS library when a process cannot be launched because the program file was not found has been changed from OMPROCESS_003 to OMPROCESS_002.

OmniMark 9.0.0

A compiled DTD (i.e., an item of sgml-dtds or xml-dtds shelf) can be replaced on the shelf without affecting its use by an outer parse.

If an element rule throws an exception, the parsed source used to be able to output to #markup-parser from an always clause. The output would be ignored. This now triggers the following run-time error: Attempting to write to a stream that is no longer in scope.

Parsing state inheritance has been streamlined. Every coroutine function call now inherits the current parsing state, with the sole exception of calls within the argument of do markup-parse, do xml-parse, and do sgml-parse which inherit the newly created parsing state. Also, throws from these function calls are no longer catchable inside the parsing scope.

The #current-output and the active groups in markup-error rules are now inherited from the point where the parse was launched.

The active groups in external-text-entity rules are now inherited from the wrapping external-text-entity rule or string source function feeding the parser, if present, and otherwise from the point where the parse was launched.

external-text-entity #dtd and other anonymous entity rules were turning off default entity processing if present in the program, even if not firing. The default external text entity processing is now enabled as a fallback, regardless of the presence of any user-defined rules. This change can cause programs that previously failed at run-time to execute successfully.

prolog-in-error rule now fires only if the parsed document prolog contains fatal errors that prevent the parser from continuing. The old behavior of prolog-in-error rules can be simulated by using prolog-end when #markup-error-count > 0.

The test doctype is now always applies to the outermost element of the parsed instance, not to the declared document element. To access the latter, use #doctype = instead. The doctype is test fails if applied outside any element, and the compiler reports an error if it is used in rules where no element can be open.

The order of evaluation of string sinks has been changed to reflect a left-to-right ordering. This may result in differences at run-time.

output-to was allowed at the top-level of a string source function: this is not well-behaved, and is no longer allowed.

The type int32 is deprecated: its use is discouraged in favour of the type integer. A warning is emitted when the type int32 is encountered in a program. Users requiring 32 bit arithmetic can use bit-level operations on the integer type to the same effect.

A warning is now emitted if the include of a file changes the currently active group. In most cases, the warning can be eliminated by putting group #implied at the end of the included file. Alternatively, the warning can be suppressed using the -warning-ignore risky-code command-line option.

A compiler warning is now emitted when the %g or %x format item is encountered alone in a string; this way of using these format items is redundant, and should be eliminated. Alternatively, you can specify -warning-ignore redundancy on the command line to suppress the warnings.

The built-in shelf #xmlns-names is now initialized with the default XML namespace prefixes prescribed by the XML Namespace standard.

The set new action on a record shelf now creates a new shelf item initialized to its default value, which is then replaced by the specified value. This change in behavior may be visible with record field initializers that have side effects.

OmniMark 8.2.0

The positional patterns value-start and value-end can now match multiple times on a string source. For example, test matches (value-start value-start) is now true.

Markup errors were interrupting pattern-matching in translate rules only if there was a markup-error rule in the program. Now they always interrupt the pattern-matching, regardless of the existence of markup-error rules.

When a string source function throws, its consumer used to be halted instantly. The throw is now delayed until the consumer finishes scanning of the terminated source.

When OMXERCES XML parser is used, all markup rules now complete their execution even after a fatal parsing error.

name of element and related syntax was accepted by the compiler in contexts where such code was guaranteed to fail at run-time (e.g., in a process rule). This is now a compile-time error. This change may cause certain programs that compiled under previous versions of OmniMark to no longer compile. However, such programs either contained code that was never executed, or would not execute successfully: there is no loss in functionality. The workaround is to remove the offending code.

A string source cast to a string was not being properly buffered. This fix can lead to changes in behavior. To obtain the old behavior, remove the string cast that precedes the string source expression.

The "%s_", "%st", and "%sn" format items now indicate that the character can be stripped by an "s" stream modifier, not that it should always be stripped.

OmniMark 8.0

OmniMark V8 is backward compatible with previous versions, with two exceptions. The first is that V8 has introduced new types and constructs which in turn makes some types obsolete. Use of these types in programs produces warnings but no change in functionality. Stilo encourages users to use the new syntax in new programs and to modify their existing programs to the new syntax, where it makes economic sense.

The second exception is external function libraries. External function libraries built to run with OmniMark V7 will not work with V8. This problem only affects customers who have built their own external function libraries. Users who only use Stilo supplied ones will not be affected.

This backward incompatibility resulted from the fix needed to stop a memory leak error in the External Function Interface. The fix to make V7 external function libraries usable with V8 is simple; just re-compile and re-link the libraries with the V8 SDK. Note that the SDK is now part of the V8 Development Package. There are no changes required to the existing library code.

OmniMark 7.1

Parentheses are no longer allowed around the list of arguments of the activate, deactivate, close, discard, and flush. Individual arguments may still be placed in parentheses. This change is necessary to allow unambiguous references to streams that are fields of records. Parenthesizing the entire argument list of these actions has never been required. Removing such parentheses will not affect program behavior.

OmniMark 7.0

External libraries compiled for version 6 or earlier must be recompiled in order to be compatible with version 7.

OmniMark 6.0

External libraries compiled for previous versions of OmniMark are not compatible with OmniMark 6. This includes both libraries supplied by OmniMark Technologies and third party libraries. Older libraries must be recompiled with the OmniMark 6 external function developers library before they can be used with OmniMark 6.

With the introduction of dynamic initializers, OmniMark no longer supports multiple global variable definitions. In earlier versions the following was legal:

     global integer message-count
     global integer message-count

Now this is not legal code. One of the declarations must be removed.

The builtins library is no longer distributed and log-message is now built into the language. Programs that used to include "builtins.xin" should no longer do so.

OmniMark 5.3

Variable name heralding was removed from the language. No longer supported are the -herald command-line option, the declaration declare heralded-names, or the keywords pattern and another. You can no longer use type names as heralds.

Programs that use variable name heralds rather than explicitly declaring variables must be rewritten to declare variables explicitly.

Programs that use variable name heralding to distinguish variables of the same name, but different types and scopes, must be rewritten to use unique variable names (where access to variables in the wider scope is required).

The rules for recognizing tokens have been changed, meaning that spaces are sometimes required between tokens where they were not required before. As a rule of thumb, always separate OmniMark tokens with spaces.

The rules for multi-value comparisons have changed. This was required to support operator overloading. The following sequence was true in previous versions, but will be false in this version:

  do when "5" < "06" < 7 

In previous versions, all comparisons were done by converting the values to numbers. In this version, the first comparison is a string-based comparison, because both its arguments are strings. The second is numeric, because it contains at least one number.

OmniMark 5.2

The default SGML declaration used by the SGML parser was changed to increase the values of certain key quantities such as NAMELEN. This could cause programs that attempt to validate SGML documents against the Reference Concrete Syntax to fail to report an error when any of these quantities exceeds the Reference Concrete Syntax default in the document being validated.

To fix programs with this problem, supply a copy of the SGML declaration for the Reference Concrete Syntax with the document you are validating.

The XML parser introduced in OmniMark 4.0 was written to a draft of the XML 1.0 specification and was incompatible with the 1.0 specification in some ways, most notably in its case-insensitive parsing of XML. The XML parser now complies with the XML 1.0 specification. This could cause programs to behave incorrectly if they do not use the correct case in markup names. It could also cause problems with input files that are not compliant with XML 1.0, but were compliant with the OmniMark 4.0 XML parser.

To fix programs with this problem, ensure that your markup names are typed correctly. Ensure that your XML files are compliant with the XML 1.0 specification.

Some programs may produce compiler error 2130, indicating that they contain potentially ambiguous attribute alias names. This is because of changes to the namecase general declaration. The namecase general and namecase entity declarations do nothing in OmniMark 5.2 and later. OmniMark now complies automatically with the NAMECASE GENERAL and NAMECASE ENTITY declarations in the SGML declaration. Earlier versions of OmniMark erroneously applied the namecase general declaration to attribute aliases. Attribute aliases are now always case insensitive. OmniMark will raise a compile-time error if this creates any ambiguity in your code. Note that this error will only occur if the namecase general no declaration is found in your program. So, if your program contains the namecase general no declaration, try to compile it once before removing the declaration to detect any potential ambiguity in your attribute alias names.

To fix programs with this problem, first check your use of attribute aliases to make sure there is no ambiguity, then remove the namecase general no declaration.

OmniMark 5.0

The initial size of variable-sized shelves was changed from 1 to 0. This will cause a run-time error in a program that assumes the default size is 1.

To fix programs with this problem, declare the affected shelves to have initial-size {1}.

OmniMark 3.0

The default program type was changed from the aided translation type "down-translate" to a normal or "process" program. Programs written as down-translate programs, but without the down-translate declaration at the top of the program, will compile but will do nothing.

To fix programs with this problem, add the following code at the top of the program:

  down-translate

All variables must be declared. Programs that use heralded names but do not declare their variables will not compile.

To fix programs with this problem, declare all the variables.

To work around this problem, for versions up to 5.3, without altering the program, use the "-herald" command-line option. For later versions you will have to change your program.