ANNEX A

(To Recommendation T.101)

Interworking data syntax (IDS)

described in ASN.1 (Recommendation X.208)

Preamble

For Videotex interchange:

a)	If two countries implement the same data syntax, then interworking can use the same data syntax (DS I, or DS II, or DS III).

b)	If two countries implement two different data syntaxes, then interworking can use either:

i)	the interworking data syntax (IDS) as defined herein, or

ii)	any one of the three data syntaxes and convert directly between DS I/DS II/DS III. The data syntaxes may be identified by the ESC 2/5 F mechanism described in S 4.4.2 of the main body of Recommendation T.101.

If the IDS is used, then the Administration in which country the data base is located will be responsible to convert into the IDS and the Administration in which country the user terminal is located will be responsible to convert from the IDS.

If the direct conversion method is used instead of using the IDS, the IDS would serve as a technical guide in designing the conversion process.

The IDS is not intended to be used in terminal to host communications.

A.1	Videotex page

A Videotex page in the interworking data syntax (IDS) is a sequence of presentation commands expressed in a manner independent of any of the terminal data syntaxes. This formulation of the presentation information which composes a Videotex page is intended to aid interworking between basically different terminal data syntaxes. It does this by isolating the unique and common elements between each of the data syntaxes. The interworking data syntax is not meant to be used as a terminal data syntax in its own right. One encoding of the interworking data syntax is that defined in Recommendation X.209. Other types of encoding are for further study.

Videotex-Page	::= SEQUENCE OF Presentation-Commands

Presentation-Commands	::= SEQUENCE { State-Vector, Function-&-Parameters }

A.2	State vector

A state victor is defined along with each presentation command to establish the relationship of that presentation command to each other presentation command. Although the information explicitly contained in the state vector is also implicitly contained within each presentation command, it would require the conversion apparatus to fully understand each of the three terminal oriented data syntaxes to uncover this information. Therefore a state vector is included with each presentation command in which a global state is affected or in which a boundary value is encountered, so that the conversion process might operate on a general level.

State-Vector	::= CHOICE { [1] Vector-Definition

[2] Reset-State-Vector,

[3] NULL }

A.2.1	Vector definition

Vector-Definition	::= SEQUENCE { Global-State-Affected-Indicator,

Terminal-Model-Precedence,

Boundary-Condition-Definition }

--	Only that information which changes between state vectors need be communicated. If there is no change in a particular component of the state vector, then that component need not be communicated. This means that the state vector is not communicated often and does not introduce significant overhead.

A.2.1.1	Global state affected indicator

The global state affected indicator carries information relating to the global states of the presentation data syntax. Global state variables are variables representing those states of the presentation data syntax which are established by presentation commands and which carry on to affect the results of subsequent presentation commands. By declaring the global state variables explicitly, it is not necessary for the conversion process to undarstand the interrelationship between presentation commands. This means that the conversion process does not have to simulate a terminal of the source data syntax in order to handle the conversion of its elements.

The global state affected indicator does not carry information about the value to which a global state has been set. That information is carried within the `Function and Parameter` section of the IDS. The indicator merely identifies which states have changed. This is of great importance in situations where it is necessary for the conversion process to sort the presentation commands to account for differences in the terminal model used in the source and destination of the interchange. If the order of presentation commands is altered, the conversion process must establish the appropriate global variables before each command in the altered sequence. By referring to the global state affected indicator, the conversion process can determine which global states must be re-established. For example, if a sorting of presentation commands is necessary to convert from a multi-plane to a single plane terminal mode, and colour control commands have been used, then the global state affected indicator will indicate that the appropriate colour state must be established ahead of each portion of the sorted data.

In some of the terminal data syntaxes attributes have global effects while in other data syntaxes the effects are localized according to the particular display primitive type. For example, in Data Syntax III a colour command remains in effect for all primitives, until the next colour command, whereas in Data Syntax II there are various colour states which apply independently to different primitives, such as LINE colour, FILLED AREA colour, etc. The global state indicator carries a reference to a number of independent `attribute state vectors` which define the attribute context. For those data syntaxes which make use of only global parameters, only one `attribute state vector` need be referenced. For other data syntaxes which make use of multiple localized attributes, several `attribute state vectors` may be referenced.

Global-State-Affected-Indicator ::= SEQUENCE {

attribute-state-vector-reference	INTEGER,

attribute-affected-indicators	SEQUENCE OF {

INTEGER {

current-text-position	(1),

current-foreground-colour	(2),

current-auxiliary-colour	(3),

lining-state	(4),

flash-blink-state	(5),

basic-char-size-state	(6),

conceal-state	(7),

char-invert-box-state	(8),

char-marking-state	(9),

screen-protection-state	(10),

display-control-state	(11),

device-control-state	(12),

cursor-control-state	(13),

geometric-control-1-state	(14),

geometric-control-2-state	(15),

wait-state	(16),

general-text-state	(17),

p-text-state	(18),

geometric-text-state	(19),

DRCS-definition-state	(20),

macro-definition-state	(21),

texture-pattern-state	(22),

music-part-memory-state	(23),

animation-configuration-state	(24),

workstation-configuration-state	(25)

} } }

--	The Global State Affected Indicator consists of a set of indicator flags which identify particular global states or in some cases categories of global states which may be altered by presentation and control commands. Some states, such as all the forms of Flashing and Blink processes, are grouped together for simplicity.

A.2.1.2	Terminal model

The terminal model differs significantly between the various terminal data syntaxes. For the presentation of static images this manifests itself in the manner by which presentation commands overlay each other. A picture developed for a multi-plane terminal model can be represented on a terminal using a single-plane terminal model or a multi-plane terminal model with a different order of precedence for the planes, by sorting the presentation commands so that they build up an equivalent picture. The sorting operation is necessary since otherwise the buildup order might conflict with the precedence order in the new environment. The terminal model precedence indicator is simply a numeric indicator of the overlay precedence for presentation commands intended by the source terminal data syntax. The conversion process is independent of the terminal model or a particular data syntax and simply sorts presentation commands based on this indicator. Note that certain commands such as resets which have an effect in more than one plane of a terminal model might have to be repeated in different parts of the presentation sequence after the sort. The terminal model precedence indicator consists of a sequence of numbers to indicate the effect of a command across the terminal model.

Terminal-Model-Precedence ::= INTEGER

tthe information is communicated. For Data Syntax I, the order is not fixed since certain `planes` of memory may be changed in precedence by the ASSIGN FRAME command.

VV	The value `0` has special meaning for the Terminal Model Precedence Indicator. It indicates that the identified information requires special interpretation. Such special information includes partial reset commands which affect more than one layer of the terminal model, as well as commands having a time dependent effect, specifically WAIT, the BEL character, and REVEAL.

A.2.1.3	Boundary conditions

Boundary condition variables represent the limits within which the particular presentation command has been defined. Each presentation command takes on its normal interpretation only within a certain range of values. For example, the number of characters which may be displayed on the screen varies between each of the source terminal data syntaxes, and therefore the operation of presenting a single character cannot be considered to be the same in each terminal data syntax. To factor out the commonality, the boundary condition of encountering the edge of the display area is identified separately from the presentation of a character. This aids conversion since it means that the boundary conditions applying to each presentation command are given explicitly. The conversion process is therefore independent of the internal boundary conditions within each of the source terminal data syntaxes.

BoundaryVConditionVDefinition ::= SET { [1] ScreenVDimensions,

[2] ColourVMapVLimit,

[3] PresentationVSubVArea,

[4] CharVModeVConstraints,

[5] CoordinateVLimitVPolygon,

[6] CoordinateVLimitVSpline,

[7] PresentationVResolution,

[8] MacroVSegVMemoryVLimit,

[9] DRCSVMemoryVLimit,

[10] DirectVColoursVLimit }

A.2.1.3.1	Screen dimensions

Screen-Dimensions	::= SEQUENCE { INTEGER, INTEGER }

--	Screen-Dimensions indicates the aspect ratio of the display screen expressed in terms of a fraction of the Y and a fraction of the X unit dimensions, where the INTEGER number represents a binary fraction with an implied binary point before the most significant bit. Note that a dimension of (1,1) implies no geometric constraint. A character mode service could use (1,1) to imply no constraint.

A.2.1.3.2	Colour map limit

Colour-Map-Limit	::= INTEGER

--	The colour map limit indicates the maximum number of colours which may be stored in a single colour map, or the combined total for multiple colour maps, and represents the maximum number of colour states which may be encountered in a particular presentation page. In the case where no colour map is used, the integer specifies the number of fixed colours.

A.2.1.3.3	Presentation sub-area

Presentation-Sub-Area	::= SEQUENCE { Abs-Coord, Rel-Coord, INTEGER, INTEGER }

--	The two coordinates give the boundary dimensions of a sub-area of the display screen both in terms of the dimensions of the sub-area and the number of characters per row and the number of columns. The absolute coordinate specifies the origin of the sub-area, the relative coordinate the size of the sub-area and the INTEGER coordinates the limit on characters per row and rows respectively.

A.2.1.3.4	Char mode constraints

Char-Mode-Constraints	::= SEQUENCE { INTEGER, INTEGER }

--	The two parameters give the limit to the number of characters per row and the number of rows of text which may be presented on the display screen; that is, the the boundaries at which character (or word) wrap and scroll will occur.

A.2.1.3.5	Coordinate limit polygon

Coordinate-Limit-Polygon	::= INTEGER

--	The polygon coordinate limit specifies the maximum number of coordinates which may be specified for a filled polygon.

A.2.1.3.6	Coordinate limit spline

Coordinate-Limit-Spline	::= INTEGER

--	The spline coordinate limit specifies the maximum number of coordinates which may be specified.

A.2.1.3.7	Presentation resolution

Presentation-Resolution	::= SEQUENCE { INTEGER, INTEGER }

--	The presentation resolution specifies the nominal resolution of the display screen which was used by the information source.

A.2.1.3.8	Macro seg memory limit

Macro-Seg-Memory-Limit	::= INTEGER

oof memory which is available for the storage of Macros or Segments. The INTEGER parameter represents available memory expressed in bytes.

A.2.1.3.9	DRCS memory limit

DRCSVMemoryVLimit	::= INTEGER

VV	The DRCS memory limit specifies the upper bound on the amount of memory which is available for the storage of DRCS. The INTEGER parameter represents available memory expressed in bytes.

A.2.1.4	Data syntax identifier (SID)

SID ::= IMPLICIT INTEGER { dataVsyntaxV I	(1),

dataVsyntaxV II	(2),

dataVsyntaxVIII	(3) }

VV	SID is an identifier which is referenced in a number of primitive commands and which identifies the source data syntax of the command.

A.2.2	Reset state vector

ResetVStateVVector ::= SEQUENCE { SID, VectorVDefinition }

VV	The Reset State Vector command is used to establish the initial state for the Interworking Data Syntax. The default state may be selected from the table corresponding to the source terminal data syntax (or profile) given in Appendix II. Alternate parameters may be specified by use of explicit state vector and function and parameter definitions.

A.2.3	NULL

NULL implies that the state vector is unchanged from the previous presentation command.

A.3	Functions and parameters

The functions and parameters which make up the presentation commands are grouped into categories which depend upon their commonality between the various terminal data syntaxes. Those functions which are compatible, such as the basic repertoire of alphanumeric characters defined in Recommendation T.51, define separate groups. Those functions which are unique, such as certain specific special characters, also establish separate groups so that they may be converted or otherwise handled in a special manner. Functions such as DRCS and graphics drawing commands, which differ in fundamental ways between the various terminal data syntaxes, are organized so that those underlying capabilities which are common may be exploited in the necessary conversion process.

FunctionsV&VParameters ::= CHOICE { [0] AlphaVCharVString,

[1] SpecialVCharVString,

[2] KanaVCharVString,

[3] KanjiVCharVString,

[4] BlockVMosaicVString,

[5] SmoothVMosaicVString,

[6] SpecialVMosaicVString,

[7] FormatVEffectorVC0VChars,

[8] SpecialVFormatVC0VCharacters,

[9] GeneralVControlVCharacters,

[10] GeometricVString,

[11] Animation-Control-String,

[12] Segment-Control-String,

[13] Colour-Control-String,

[14] Text-Control-String,

[15] Photo-Graphic-String-Syntetic-Image,

[16] Photo-Graphic-String-Natural-Image,

[17] MACRO-String,

[18] DRCS-String,

[19] Fill Pattern-Control-String,

[20] Music-String,

[21] Tele-Software-String,

[22] Audio-Data-String,

[23] Greek-Char-String }

The first six categories of functions and the last one are various text or mosaic characters. None of the terminal data syntaxes defined in Recommendation T.101 encompasses all of these characters. There are different unique characters in each of the terminal data syntaxes. However, a large portion of the repertoire is common between the different terminal data syntaxes, although the characters may be coded differently. Since coding is irrelevant here, and the use of particular tables could in fact cause serious confusion, characters extracted from the different character repertoires will be distinguished by the identifier name codes for each character as defined in Recommendation T.51. Since all of the terminal-oriented data syntaxes in Recommendation T.101 do not explicitly make use of these name codes in the body of the Recommendation, the entire character repertoire, together with the name codes for each character are included here as an appendix.

A.3.0	Alpha char string

Alpha-Char-String	::= GRAPHICSTRING

--	Characters (LA01 to LZ30, ND01 to ND09 and ND10, SC01 to SC05, SP01 to SP22, SA01 to SA07, NS01 to NS03, NF01 to NF21, SM01 to SM44 and SM47 to SM49, and SD11 to SD43) taken from Repertoire 1 which are the characters from the primary and supplementary character sets of Recommendation T.51 together with the SPACE character (SP01) and DELETE character (SM34).

--	The coding of characters within an Alpha Character String will be taken from the IRV primary character code table (ISO Registration Number 2 under ISO 2375) and the secondary code table for use with IRV from ISO 6937/2 (ISO Registration Number 90).

--	Note - The coding for the character $ "Dollar Sign" (SC02) will be taken from the supplementary character set.

--	Note - The coding for the character ## "number sign" (SM01) will be taken from the primary character set.

--	Note - The coding for the character "general currency sign" (SC01) will be taken from the primary character set.

A.3.1	Special char string

Special-Char-String	::= INTEGER { non-spacing-vector-overbar	(1),

non-spacing-slant	(2),

left-vertical-bar-jointive	(3),

right-vertical-bar-jointive	(4) }

--	Non-Spacing-Vector-Overbar is a character (SM50) from Repertoire 2.

--	Non-Spacing-Slant is a character (SM51) from Repertoire 2.

--	Left-Vertical-Bar-Jointive is a character (SM45) from Repertoire 2.

--	Right-Vertical-Bar-Jointive is a character (SM46) from Repertoire 2.

A.3.2	Kana char string

Kana-Char-String	::= GRAPHICSTRING

--	Characters (JA01 to JA63) taken from Repertoire 3.

--	The coding of characters within a Kana Character String will be taken from the Kana character code table (ISO Registration Number 56 under ISO 2375).

A.3.3	Kanji char string

Kanji-Char-String	::= GRAPHICSTRING

--	Characters (JK01 to JK2980, HK01 to HK83, and JS01 to JS366) from Repertoire 4.

--	The coding of characters within a Kanji Character String will be taken from the two byte Kanji character code table (ISO Registration Number 87 under ISO 2375).