IBM Integration Bus, Version 10.0.0.17 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS


Other common MRM entities

This file is used as a common entities file for all MRM information that is not physical format related.

Details of this text reuse file

This file is used to contain information that is common to the MRM documentation, but not common to a specific layer; for example, logical or CWF layers.

In some cases it is a simple text phrase that is defined here for use (through the conref mechanism) where required in the documentation. In others it defines tables or rows of tables that are used in multiple topics within the documentation.

The following tables define the properties of objects that are common for multiple topics. The properties have been grouped together where they appear grouped in the product.

Some tables or sections are used as a whole, but most tables just contain the rows that define the object property. To view the row ID you need to view the table markup. In the table markup, the row ID is displayed as an attribute.

In most cases, there is a single row for a property where no differences occur between where it is used for each object or object type. In other cases, multiple rows occur for each property where differences occur in the meaning of each object type of a property; for example, binary, Boolean, string, and so on. Occasionally, where there are differences, a common row is defined that contains all the information required, and rows are built beneath that one that contain links to the specific information for building the description of that property for that type.

Extreme care must be taken when editing this file to ensure that the changes that you make only affect those topics that need to be changed. In some cases, this common information is used in more than 50 topics.

Simple text strings - Keep in alphabetical order

......for message set stuff

Min

Max

Min Occurs

Max Occurs

Binary schema types: base64Binary, hexBinary

Boolean schema types: Boolean

DateTime schema types: date, dateTime, gDay, gMonth, gMonthDay, gYear, gYearMonth, time

Decimal schema types: decimal, integer, negativeInteger, nonNegativeInteger, nonPositiveInteger, positiveInteger, unsignedLong

Float schema types: double, float

Integer schema types: byte, int, long, short, unsignedByte, unsignedInt, unsignedShort

Interval schema types: duration

String schema types: anyURI, ENTITIES, ENTITY, ID, IDREF, IDREFS, language, Name, NCName, NMTOKEN, NMTOKENS, normalizedString, NOTATION, QName, string, token

Common paragraph

The properties that are displayed on the object page, and the values that those properties can take, can vary according to the type of the object. For example, the properties for type string are different from those of type Boolean. Select the link for the object type from the following table.

Common "no properties" section

There are no properties to show.

DateTime settings

Property Type Meaning
Derive default dateTime format from logical type Button Select this option if you want the default dateTime format to be determined by the logical type of the element or attribute.

You can override this property for an element or attribute within a complex type.

Use default dateTime format Button and String Select this option if you want to specify a default dateTime format that is fixed for all elements or attributes of logical type dateTime, date, time, gYear, gYearMonth, gMonth, gMonthDay, and gDay.

You can override this property for an element or attribute within a complex type.

For more information, see Message Sets: DateTime formats.

Start of century for 2-digit years Integer This property determines how 2-digit years are interpreted. Specify the two digits that start a 100-year window that contains the current year. For example, if you specify 89, and the current year is 2002, all 2-digit dates are interpreted as being in the range 1989 - 2088.
Days in First Week of Year Enumerated Specify the number of days of the new year that must fall within the first week.

The start of a year typically falls in the middle of a week. If the number of days in that week is less than the value specified here, the week is considered to be the last week of the previous year; therefore, week 1 starts some days into the new year. Otherwise, it is considered to be the first week of the new year; in this case, week 1 starts some days before the new year.

Select Use Broker Locale, which causes the integration node to get the information from the underlying platform, or select a number from the list that is displayed.

First Day Of Week Enumerated Specify the day on which each new week starts.

Select Use Broker Locale, which causes the integration node to get the information from the underlying platform, or select a value from the list that is displayed.

Strict DateTime Checking Check box Select this option if you want to restrict dateTimes to a valid dateTime format. If Strict DateTime Checking is selected, receiving an incorrect dateTime causes an error.
Strict dateTime checking
Examples of strict dateTime checking are:
  • DateTimes are restricted to valid dateTimes only. When you use this option, a date such as the 35th March is not processed as 4th April, and 10:79 is not processed as 11:19. Receiving an out-of-band dateTime, such as these examples, causes an error to occur.
  • The number of characters for a numeric dateTime component must be within the bounds of the corresponding formatting symbols. Repeat the symbol to specify the minimum number of digits that you require. The maximum number of digits that is permitted becomes the upper bound for a particular symbol. For example, day in month has an upper bound of 31; therefore, a format string of 'd' allows the values 2 and 21 to be parsed, but does not allow the values 32 and 210. On output, numbers are padded with zeros to the specified length. A year is a special case; see the message set property Start of century for 2 digit years. For fractional seconds, the length must implicitly match the number of format symbols on input. The output is rounded to the specified length.
  • White space is not skipped over. The white space in the input string must correspond with the same number and position of white space in the formatting string.
  • If data remains that is not parsed in the input string after all the symbols in the formatting string have been matched, an error occurs.
Lenient dateTime checking
Examples of lenient dateTime checking are:
  • The parser converts out-of-band dateTime values to the appropriate in-band value. For example, a date of 2005-05-32 is converted to 2005-06-01.
  • Output of dateTimes always adheres to the symbol count. For example, a formatting string of yyyy-MM-dd (where '-' is the field separator) allows one or more characters to be parsed against MM and dd. Therefore, dates that are not valid - for example, 2005-1-123 and 2005-011-12 - can be entered. The first value of 2005-1-123 is output as the date 2005-05-03, and the second value of 2005-011-12 is output as the date 2005-11-12.
  • The number of the timezone formatting symbol Z is applicable only to the output dateTime format.
  • White space is skipped over.
Time Zone Enumerated The value that you set for this property is used if the value that you specified for the Default DateTime Format property does not include Time Zone information.

The initial value is Use Broker Locale, which causes the integration node to get the information from the underlying platform.

You can change this property by selecting from the list of values.

Daylight Saving Time Check box Select this option if the area in the Time Zone property observes daylight saving time. If it does not observe daylight saving time, do not select this option.

For example, if an area is selected in Time Zone and this option is not selected, the value passed represents the time zone without the daylight saving time.

Use input UTC format on output Check box This property applies to elements and attributes of logical type xsd:dateTime or xsd:time that have a dateTime format of I, IU, T, or TU, or that include ZZZ or ZZZU.

Such elements and attributes can specify Coordinated Universal Time (UTC) by using either the Z character or timezone +00:00 in the value. On input, the MRM parser remembers the way that UTC was specified.

If this property is selected, and the element or attribute is copied to an output message, the UTC format is preserved into the output message and overrides the format that is implied by the dateTime format property.

If this property is cleared, or the element or attribute was not copied from an input message, the UTC format in the output message is controlled solely by the dateTime format property.

Use input UTC format on output Check box This property applies to elements and attributes of logical type xsd:dateTime or xsd:time that contain a dateTime as a string and that have a dateTime format of I, IU, T, or TU, or that include ZZZ or ZZZU.

Such elements and attributes can specify Coordinated Universal Time (UTC) by using either the Z character or timezone +00:00 in the value. On input, the MRM parser remembers the way that UTC was specified.

If this property is selected, and the element or attribute is copied to an output message, the UTC format is preserved into the output message and overrides the format that is implied by the dateTime format property.

If this property is cleared, or if the element or attribute was not copied from an input message, the UTC format in the output message is controlled solely by the dateTime format property.

Section for common table

Note about duration

Note: The physical format properties for simple type duration are the same as the physical properties of the string logical types.

Section for second common table


adothent.htm | Last updated 2019-07-13 08:12:41