However, it is not strictly necessary to include every column in both images, and we can often save disk, memory, and network usage by logging only those columns which are actually required. When deleting a row, only the before image is logged, since there are no changed values to propagate following the deletion. When inserting a row, only the after image is logged, since there is no existing row to be matched.

Only when updating a row are both the before and after images required, and both written to the binary log. For the before image, it is necessary only that the minimum set of columns required to uniquely identify rows is logged. If the table containing the row has a primary key, then only the primary key column or columns are written to the binary log.

Otherwise, if the table has a unique key all of whose columns are NOT NULL , then only the columns in the unique key need be logged. If the table has neither a primary key nor a unique key without any NULL columns, then all columns must be used in the before image, and logged. In the after image, it is necessary to log only the columns which have actually changed. This variable actually takes one of three possible values, as shown in the following list:. full : Log all columns in both the before image and the after image.

minimal : Log only those columns in the before image that are required to identify the row to be changed; log only those columns in the after image where a value was specified by the SQL statement, or generated by auto-increment. noblob : Log all columns same as full , except for BLOB and TEXT columns that are not required to identify rows, or that have not changed.

This variable is not supported by NDB Cluster; setting it has no effect on the logging of NDB tables. When using minimal or noblob , deletes and updates are guaranteed to work correctly for a given table if and only if the following conditions are true for both the source and destination tables:.

All columns must be present and in the same order; each column must use the same data type as its counterpart in the other table. In other words, the tables must be identical with the possible exception of indexes that are not part of the tables' primary keys.

If these conditions are not met, it is possible that the primary key column values in the destination table may prove insufficient to provide a unique match for a delete or update. In this event, no warning or error is issued; the source and replica silently diverge, thus breaking consistency. Setting this variable has no effect when the binary logging format is STATEMENT.

Configures the amount of table metadata added to the binary log when using row-based logging. When set to MINIMAL , the default, only metadata related to SIGNED flags, column character set and geometry types are logged. When set to FULL complete metadata for tables is logged, such as column name, ENUM or SET string values, PRIMARY KEY information, and so on.

Replicas use the metadata to transfer data when its table structure is different from the source's. External software can use the metadata to decode row events and store the data into external databases, such as a data warehouse. If the server is unable to generate a partial update, the full document is used instead.

The default value is an empty string, which disables use of the format. mysqlbinlog output includes partial JSON updates in the form of events encoded as base strings using BINLOG statements. If the --verbose option is specified, mysqlbinlog displays the partial JSON updates as readable JSON using pseudo-SQL statements. MySQL Replication generates an error if a modification cannot be applied to the JSON document on the replica.

This includes a failure to find the path. Be aware that, even with this and other safety checks, if a JSON document on a replica has diverged from that on the source and a partial update is applied, it remains theoretically possible to produce a valid but unexpected JSON document on the replica. This system variable affects row-based logging only. When enabled, it causes the server to write informational log events such as row query log events into its binary log.

This information can be used for debugging and related purposes, such as obtaining the original query issued on the source when it cannot be reconstructed from the row updates. These informational events are normally ignored by MySQL programs reading the binary log and so cause no issues when replicating or restoring from backup. To view them, increase the verbosity level by using mysqlbinlog's --verbose option twice, either as -vv or --verbose --verbose.

The size of the memory buffer for the binary log to hold nontransactional statements issued during a transaction. If the data for the nontransactional statements used in the transaction exceeds the space in the memory buffer, the excess data is stored in a temporary file. After each transaction is committed, the binary log statement cache is reset by clearing the memory buffer and truncating the temporary file if used. If you often use large nontransactional statements during transactions, you can increase this cache size to get better performance by reducing or eliminating the need to write to temporary files.

Enables compression for transactions that are written to binary log files on this server. Compressed transaction payloads remain in a compressed state while they are sent in the replication stream to replicas, other Group Replication group members, or clients such as mysqlbinlog , and are written to the relay log still in their compressed state. Binary log transaction compression therefore saves storage space both on the originator of the transaction and on the recipient and for their backups , and saves network bandwidth when the transactions are sent between server instances.

When a MySQL server instance has no binary log, if it is at a release from MySQL 8. Compressed transaction payloads received by such server instances are written in their compressed state to the relay log, so they benefit indirectly from compression carried out by other servers in the replication topology. This system variable cannot be changed within the context of a transaction.

For more information on binary log transaction compression, including details of what events are and are not compressed, and changes in behavior when transaction compression is in use, see Section 5. Prior to NDB 8. In NDB 8. See the description of the variable for further information. The value is an integer that determines the compression effort, from 1 the lowest effort to 22 the highest effort.

If you do not specify this system variable, the compression level is set to 3. As the compression level increases, the data compression ratio increases, which reduces the storage space and network bandwidth required for the transaction payload.

However, the effort required for data compression also increases, taking time and CPU and memory resources on the originating server. Increases in the compression effort do not have a linear relationship to increases in the data compression ratio. This variable has no effect on logging of transactions on NDB tables; in NDB Cluster 8. The dependency information written by the replication source is represented using logical timestamps.

There are two logical timestamps, listed here, for each transaction:. The numbering restarts with 1 in each binary log file. Available choices are listed here:. This the default. The commit-time window begins immediately following the execution of the last statement of the transaction, and ends immediately after the storage engine commit ends. Since transactions hold all row locks between these two points in time, we know that they cannot update the same rows.

Each row in the transaction adds a set of one or more hashes to the transaction's write set, one of each unique key in the row. If there are no unique, nonnullable keys, a hash of the row is used.

This includes both deleted and inserted rows; for updated rows, both the old and the new row are also included. Two transactions are considered conflicting if their write sets overlap—that is, if there is some number hash that occurs in the write sets of both transactions.

In addition, due to the way the write sets are computed, there are periodic serialization points, such that the write set computation process regards every transaction after a serialization point as conflicting with every transaction before the serialization point. Serialization points affect only dependencies computed by the WRITESET algorithm; transactions on opposite sides of the serialization point may have overlapping commit-time windows, and so can be parallelized on replica in spite of this.

The transactions are dependent according to WRITESET. The transactions were committed in the same user session. Any change in the value does not take effect for replicated transactions until after the replica has been stopped and restarted with STOP REPLICA and START REPLICA. The dependency information in those logs is used to assist the process of state transfer from a donor's binary log for distributed recovery, which takes place whenever a member joins or rejoins the group.

Sets an upper limit on the number of row hashes which are kept in memory and used for looking up the transaction that last modified a given row. Once this number of hashes has been reached, the history is purged. Specifies the number of days before automatic removal of binary log files. If you do not set a value for either system variable, the default expiration period is 30 days.

A warning message is issued in this situation. Shows the status of binary logging on the server, either enabled ON or disabled OFF. ON means that the binary log is available, OFF means that it is not in use. The --log-bin option can be used to specify a base name and location for the binary log.

Holds the base name and path for the binary log files, which can be set with the --log-bin server option. The maximum variable length is For compatibility with MySQL 5. The default location is the data directory. Holds the base name and path for the binary log index file, which can be set with the --log-bin-index server option. This variable applies when binary logging is enabled.

It controls whether stored function creators can be trusted not to create stored functions that may cause unsafe events to be written to the binary log. If set to 0 the default , users are not permitted to create or alter stored functions unless they have the SUPER privilege in addition to the CREATE ROUTINE or ALTER ROUTINE privilege.

If the variable is set to 1, MySQL does not enforce these restrictions on stored function creation. This variable also applies to trigger creation. This read-only system variable is deprecated.

Setting the system variable to ON at server startup enabled row-based replication with replicas running MySQL Server 5. In releases before MySQL 8. Enabling this variable causes the replica to write the updates that are received from a source and performed by the replication SQL thread to the replica's own binary log.

Binary logging, which is controlled by the --log-bin option and is enabled by default, must also be enabled on the replica for updates to be logged. For example, you might want to set up replication servers using this arrangement:. Here, A serves as the source for the replica B , and B serves as the source for the replica C. For this to work, B must be both a source and a replica. If error is encountered, controls whether the generated warnings are added to the error log or not.

The minimum value is The maximum possible value is 16EiB exbibytes. The maximum recommended value is 4GB; this is due to the fact that MySQL currently cannot work with binary log positions greater than 4GB. If a write to the binary log causes the current log file size to exceed the value of this variable, the server rotates the binary logs closes the current file and opens the next one. The minimum value is bytes.

The maximum and default value is 1GB. A transaction is written in one chunk to the binary log, so it is never split between several binary logs. If nontransactional statements within a transaction require more than this many bytes of memory, the server generates an error. The maximum and default values are 4GB on bit platforms and 16EB exabytes on bit platforms. For internal use by replication. When re-executing a transaction on a replica, this is set to the time when the transaction was committed on the original source, measured in microseconds since the epoch.

This allows the original commit timestamp to be propagated throughout a replication topology. However, note that the variable is not intended for users to set; it is set automatically by the replication infrastructure. This variable controls whether logging to the binary log is enabled for the current session assuming that the binary log itself is enabled. The default value is ON.

Set this variable to OFF for a session to temporarily disable binary logging while making changes to the source you do not want replicated to the replica. Setting this variable to OFF prevents GTIDs from being assigned to transactions in the binary log. If you are using GTIDs for replication, this means that even when binary logging is later enabled again, the GTIDs written into the log from this point do not account for any transactions that occurred in the meantime, so in effect those transactions are lost.

Controls how often the MySQL server synchronizes the binary log to disk. Instead, the MySQL server relies on the operating system to flush the binary log to disk from time to time as it does for any other file. This setting provides the best performance, but in the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been synchronized to the binary log.

This is the safest setting but can have a negative impact on performance due to the increased number of disk writes. In the event of a power failure or operating system crash, transactions that are missing from the binary log are only in a prepared state. This permits the automatic recovery routine to roll back the transactions, which guarantees that no transaction is lost from the binary log.

In the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been flushed to the binary log. This setting can have a negative impact on performance due to the increased number of disk writes. A higher value improves performance, but with an increased risk of data loss. For the greatest possible durability and consistency in a replication setup that uses InnoDB with transactions, use these settings:.

Many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken place, even though it has not. In this case, the durability of transactions is not guaranteed even with the recommended settings, and in the worst case, a power outage can corrupt InnoDB data. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer.

You can also try to disable the caching of disk writes in hardware caches. This system variable specifies the algorithm used to hash the writes extracted during a transaction. The default is XXHASH OFF means that write sets are not collected.

The XXHASH64 setting is required for Group Replication, where the process of extracting the writes from a transaction is used for conflict detection and certification on all group members see Section If you change the value, the new value does not take effect on replicated transactions until after the replica has been stopped and restarted with STOP REPLICA and START REPLICA.

Documentation Home MySQL 8. MySQL Server Administration. The InnoDB Storage Engine. Configuring Replication. Binary Log File Position Based Replication Configuration Overview. Setting Up Binary Log File Position Based Replication. Setting the Replication Source Configuration. Setting the Replica Configuration. Creating a User for Replication. Obtaining the Replication Source Binary Log Coordinates. Choosing a Method for Data Snapshots. Setting Up Replicas. Setting the Source Configuration on the Replica.

Adding Replicas to a Replication Environment. Replication with Global Transaction Identifiers. GTID Format and Storage. GTID Auto-Positioning. Setting Up Replication Using GTIDs. Using GTIDs for Failover and Scaleout. Replication From a Source Without GTIDs to a Replica With GTIDs. Restrictions on Replication with GTIDs. Stored Function Examples to Manipulate GTIDs. Changing GTID Mode on Online Servers. Replication Mode Concepts.

Enabling GTID Transactions Online. Disabling GTID Transactions Online. Verifying Replication of Anonymous Transactions. MySQL Multi-Source Replication. Configuring Multi-Source Replication.

Provisioning a Multi-Source Replica for GTID-Based Replication. Adding GTID-Based Sources to a Multi-Source Replica. Adding Binary Log Based Replication Sources to a Multi-Source Replica. Starting Multi-Source Replicas. Stopping Multi-Source Replicas. Resetting Multi-Source Replicas. Monitoring Multi-Source Replication. Replication and Binary Logging Options and Variables.

Replication and Binary Logging Option and Variable Reference. Replication Source Options and Variables. Replica Server Options and Variables.

Binary Logging Options and Variables. Global Transaction ID System Variables. Common Replication Administration Tasks. Checking Replication Status. Pausing Replication on the Replica. Skipping Transactions. Replication Implementation. Advantages and Disadvantages of Statement-Based and Row-Based Replication. Usage of Row-Based Logging and Replication. Determination of Safe and Unsafe Statements in Binary Logging. Commands for Operations on a Single Channel. Compatibility with Previous Replication Statements.

Startup Options and Replication Channels. Replication Channel Naming Conventions. Replication Threads. Monitoring Replication Main Threads. Monitoring Replication Applier Worker Threads. Relay Log and Replication Metadata Repositories. Replication Metadata Repositories.

How Servers Evaluate Replication Filtering Rules. Evaluation of Database-Level Replication and Binary Logging Options. Evaluation of Table-Level Replication Options. Interactions Between Replication Filtering Options. Replication Channel Based Filters. Setting Up Replication to Use Encrypted Connections. Encrypting Binary Log Files and Relay Log Files. Scope of Binary Log Encryption.

Binary Log Encryption Keys. Binary Log Master Key Rotation. Replication Privilege Checks. Privilege Checks For Group Replication Channels.

Recovering From Failed Replication Privilege Checks. Using Replication for Backups. Backing Up a Replica Using mysqldump. Backing Up Raw Data from a Replica. Backing Up a Source or Replica by Making It Read Only. Handling an Unexpected Halt of a Replica. Monitoring Row-based Replication. Using Replication with Different Source and Replica Storage Engines.

Using Replication for Scale-Out. Replicating Different Databases to Different Replicas. Improving Replication Performance. Switching Sources During Failover. Switching Sources and Replicas with Asynchronous Connection Failover. Asynchronous Connection Failover for Sources.

Asynchronous Connection Failover for Replicas. Semisynchronous Replication. Installing Semisynchronous Replication. Configuring Semisynchronous Replication. Semisynchronous Replication Monitoring. Replication Features and Issues. Replication and BLACKHOLE Tables. Replication and Character Sets.

Replication and CHECKSUM TABLE. Replication of CREATE SERVER, ALTER SERVER, and DROP SERVER. Replication of CREATE IF NOT EXISTS Statements.

Replication of CREATE TABLE SELECT Statements. Replication with Differing Table Definitions on Source and Replica.

hexBinary has the following · constraining facets · :. The · value space · of base64Binary is the set of finite-length sequences of binary octets. For base64Binary data the entire binary stream is encoded using the Base64 Alphabet in [RFC ]. The lexical forms of base64Binary values are limited to the 65 characters of the Base64 Alphabet defined in [RFC ] , i.

No other characters are allowed. For compatibility with older mail gateways, [RFC ] suggests that base64 data should have lines limited to at most 76 characters in length. This line-length limitation is not mandated in the lexical forms of base64Binary data and must not be enforced by XML Schema processors. The lexical space of base64Binary is given by the following grammar the notation is that used in [XML 1. Note that this grammar requires the number of non-whitespace characters in the lexical form to be a multiple of four, and for equals signs to appear only at the end of the lexical form; strings which do not meet these constraints are not legal lexical forms of base64Binary because they cannot successfully be decoded by base64 decoders.

The canonical lexical form of a base64Binary data value is the base64 encoding of the value which matches the Canonical-base64Binary production in the following grammar:.

The length of a base64Binary value is the number of octets it contains. This may be calculated from the lexical form by removing whitespace and padding characters and performing the calculation shown in the pseudo-code below:. Note on encoding: [RFC ] explicitly references US-ASCII encoding.

However, decoding of base64Binary data in an XML entity is to be performed on the Unicode characters obtained after character encoding processing as specified by [XML 1. base64Binary has the following · constraining facets · :.

An anyURI value can be absolute or relative, and may have an optional fragment identifier i. This type should be used to specify the intention that the value fulfills the role of a URI as defined by [RFC ] , as amended by [RFC ]. The mapping from anyURI values to URIs is as defined by the URI reference escaping procedure defined in Section 5. This means that a wide range of internationalized resource identifiers can be specified when an anyURI is called for, and still be understood as URIs per [RFC ] , as amended by [RFC ] , where appropriate to identify resources.

The · lexical space · of anyURI is finite-length character sequences which, when the algorithm defined in Section 5.

anyURI has the following · constraining facets · :. The · value space · of QName is the set of tuples { namespace name , local part }, where namespace name is an anyURI and local part is an NCName. The · lexical space · of QName is the set of strings that · match · the QName production of [Namespaces in XML].

QName has the following · constraining facets · :. The use of · length · , · minLength · and · maxLength · on datatypes · derived · from QName is deprecated. Future versions of this specification may remove these facets for this datatype.

The · value space · of NOTATION is the set of QName s of notations declared in the current schema. The · lexical space · of NOTATION is the set of all names of notations declared in the current schema in the form of QName s. For compatibility see Terminology §1. NOTATION has the following · constraining facets · :.

The use of · length · , · minLength · and · maxLength · on datatypes · derived · from NOTATION is deprecated. This section gives conceptual definitions for all · built-in · · derived · datatypes defined by this specification. The XML representation used to define · derived · datatypes whether · built-in · or · user-derived · is given in section XML Representation of Simple Type Definition Schema Components §4. The · value space · of normalizedString is the set of strings that do not contain the carriage return xD , line feed xA nor tab x9 characters.

The · lexical space · of normalizedString is the set of strings that do not contain the carriage return xD , line feed xA nor tab x9 characters. The · base type · of normalizedString is string. normalizedString has the following · constraining facets · :. The following · built-in · datatypes are · derived · from normalizedString :. The · value space · of token is the set of strings that do not contain the carriage return xD , line feed xA nor tab x9 characters, that have no leading or trailing spaces x20 and that have no internal sequences of two or more spaces.

The · lexical space · of token is the set of strings that do not contain the carriage return xD , line feed xA nor tab x9 characters, that have no leading or trailing spaces x20 and that have no internal sequences of two or more spaces.

The · base type · of token is normalizedString. token has the following · constraining facets · :. The following · built-in · datatypes are · derived · from token :.

The · value space · of language is the set of all strings that are valid language identifiers as defined [RFC ]. The · base type · of language is token.

language has the following · constraining facets · :. The · value space · of NMTOKEN is the set of tokens that · match · the Nmtoken production in [XML 1. The · lexical space · of NMTOKEN is the set of strings that · match · the Nmtoken production in [XML 1. The · base type · of NMTOKEN is token. NMTOKEN has the following · constraining facets · :. The following · built-in · datatypes are · derived · from NMTOKEN :. The · value space · of NMTOKENS is the set of finite, non-zero-length sequences of · NMTOKEN · s.

The · lexical space · of NMTOKENS is the set of space-separated lists of tokens, of which each token is in the · lexical space · of NMTOKEN. The · itemType · of NMTOKENS is NMTOKEN. NMTOKENS has the following · constraining facets · :. The · value space · of Name is the set of all strings which · match · the Name production of [XML 1. The · lexical space · of Name is the set of all strings which · match · the Name production of [XML 1. The · base type · of Name is token. Name has the following · constraining facets · :.

The following · built-in · datatypes are · derived · from Name :. The · value space · of NCName is the set of all strings which · match · the NCName production of [Namespaces in XML]. The · lexical space · of NCName is the set of all strings which · match · the NCName production of [Namespaces in XML].

The · base type · of NCName is Name. NCName has the following · constraining facets · :. The following · built-in · datatypes are · derived · from NCName :. The · value space · of ID is the set of all strings that · match · the NCName production in [Namespaces in XML]. The · lexical space · of ID is the set of all strings that · match · the NCName production in [Namespaces in XML].

The · base type · of ID is NCName. ID has the following · constraining facets · :. The · value space · of IDREF is the set of all strings that · match · the NCName production in [Namespaces in XML].

The · lexical space · of IDREF is the set of strings that · match · the NCName production in [Namespaces in XML]. The · base type · of IDREF is NCName. IDREF has the following · constraining facets · :.

The following · built-in · datatypes are · derived · from IDREF :. The · value space · of IDREFS is the set of finite, non-zero-length sequences of IDREF s. The · lexical space · of IDREFS is the set of space-separated lists of tokens, of which each token is in the · lexical space · of IDREF.

The · itemType · of IDREFS is IDREF. IDREFS has the following · constraining facets · :. The · value space · of ENTITY is the set of all strings that · match · the NCName production in [Namespaces in XML] and have been declared as an unparsed entity in a document type definition. The · lexical space · of ENTITY is the set of all strings that · match · the NCName production in [Namespaces in XML].

The · base type · of ENTITY is NCName. ENTITY has the following · constraining facets · :. The following · built-in · datatypes are · derived · from ENTITY :. The · value space · of ENTITIES is the set of finite, non-zero-length sequences of · ENTITY · s that have been declared as unparsed entities in a document type definition. The · lexical space · of ENTITIES is the set of space-separated lists of tokens, of which each token is in the · lexical space · of ENTITY.

The · itemType · of ENTITIES is ENTITY. ENTITIES has the following · constraining facets · :. This results in the standard mathematical concept of the integer numbers. The · value space · of integer is the infinite set { The · base type · of integer is decimal. integer has a lexical representation consisting of a finite-length sequence of decimal digits x x39 with an optional leading sign.

The canonical representation for integer is defined by prohibiting certain options from the Lexical representation §3. integer has the following · constraining facets · :. The following · built-in · datatypes are · derived · from integer :. This results in the standard mathematical concept of the non-positive integers.

The · value space · of nonPositiveInteger is the infinite set { The · base type · of nonPositiveInteger is integer. nonPositiveInteger has a lexical representation consisting of an optional preceding sign followed by a finite-length sequence of decimal digits x x For example: -1, 0, , The canonical representation for nonPositiveInteger is defined by prohibiting certain options from the Lexical representation §3.

In the canonical form for zero, the sign must be omitted. Leading zeroes are prohibited. nonPositiveInteger has the following · constraining facets · :. The following · built-in · datatypes are · derived · from nonPositiveInteger :. This results in the standard mathematical concept of the negative integers. The · value space · of negativeInteger is the infinite set { The · base type · of negativeInteger is nonPositiveInteger.

negativeInteger has a lexical representation consisting of a negative sign "-" followed by a finite-length sequence of decimal digits x x For example: -1, , The canonical representation for negativeInteger is defined by prohibiting certain options from the Lexical representation §3.

Specifically, leading zeroes are prohibited. negativeInteger has the following · constraining facets · :. The · base type · of long is integer. long has a lexical representation consisting of an optional sign followed by a finite-length sequence of decimal digits x x The canonical representation for long is defined by prohibiting certain options from the Lexical representation §3. long has the following · constraining facets · :.

The following · built-in · datatypes are · derived · from long :. The · base type · of int is long. int has a lexical representation consisting of an optional sign followed by a finite-length sequence of decimal digits x x The canonical representation for int is defined by prohibiting certain options from the Lexical representation §3.

int has the following · constraining facets · :. The following · built-in · datatypes are · derived · from int :. The · base type · of short is int. short has a lexical representation consisting of an optional sign followed by a finite-length sequence of decimal digits x x The canonical representation for short is defined by prohibiting certain options from the Lexical representation §3.

short has the following · constraining facets · :. The following · built-in · datatypes are · derived · from short :. The · base type · of byte is short. byte has a lexical representation consisting of an optional sign followed by a finite-length sequence of decimal digits x x The canonical representation for byte is defined by prohibiting certain options from the Lexical representation §3. byte has the following · constraining facets · :.

This results in the standard mathematical concept of the non-negative integers. The · value space · of nonNegativeInteger is the infinite set {0,1,2, The · base type · of nonNegativeInteger is integer. nonNegativeInteger has a lexical representation consisting of an optional sign followed by a finite-length sequence of decimal digits x x The canonical representation for nonNegativeInteger is defined by prohibiting certain options from the Lexical representation §3.

nonNegativeInteger has the following · constraining facets · :. The following · built-in · datatypes are · derived · from nonNegativeInteger :. The · base type · of unsignedLong is nonNegativeInteger.

unsignedLong has a lexical representation consisting of a finite-length sequence of decimal digits x x For example: 0, , The canonical representation for unsignedLong is defined by prohibiting certain options from the Lexical representation §3. unsignedLong has the following · constraining facets · :. The following · built-in · datatypes are · derived · from unsignedLong :. The · base type · of unsignedInt is unsignedLong.

unsignedInt has a lexical representation consisting of a finite-length sequence of decimal digits x x The canonical representation for unsignedInt is defined by prohibiting certain options from the Lexical representation §3. unsignedInt has the following · constraining facets · :. The following · built-in · datatypes are · derived · from unsignedInt :. The · base type · of unsignedShort is unsignedInt.

unsignedShort has a lexical representation consisting of a finite-length sequence of decimal digits x x The canonical representation for unsignedShort is defined by prohibiting certain options from the Lexical representation §3.

Specifically, the leading zeroes are prohibited. unsignedShort has the following · constraining facets · :. The following · built-in · datatypes are · derived · from unsignedShort :. The · base type · of unsignedByte is unsignedShort. unsignedByte has a lexical representation consisting of a finite-length sequence of decimal digits x x The canonical representation for unsignedByte is defined by prohibiting certain options from the Lexical representation §3.

unsignedByte has the following · constraining facets · :. This results in the standard mathematical concept of the positive integer numbers. The · value space · of positiveInteger is the infinite set {1,2, The · base type · of positiveInteger is nonNegativeInteger. The canonical representation for positiveInteger is defined by prohibiting certain options from the Lexical representation §3.

positiveInteger has the following · constraining facets · :. The following sections provide full details on the properties and significance of each kind of schema component involved in datatype definitions. For each property, the kinds of values it is allowed to have is specified. Any property not identified as optional is required to be present; optional properties which are not present have absent as their value.

Any property identified as a having a set, subset or · list · value may have an empty value unless this is explicitly ruled out: this is not the same as absent. Any property value identified as a superset or a subset of some set may be equal to that set, unless a proper superset or subset is explicitly called for. For more information on the notion of datatype schema components, see Schema Component Details of [XML Schema Part 1: Structures].

Datatypes are identified by their {name} and {target namespace}. Except for anonymous datatypes those with no {name} , datatype definitions · must · be uniquely identified within a schema. If {variety} is · atomic · then the · value space · of the datatype defined will be a subset of the · value space · of {base type definition} which is a subset of the · value space · of {primitive type definition}.

If {variety} is · list · then the · value space · of the datatype defined will be the set of finite-length sequence of values from the · value space · of {item type definition}. If {variety} is · union · then the · value space · of the datatype defined will be the union of the · value space · s of each datatype in {member type definitions}. If {variety} is · atomic · then the {variety} of {base type definition} must be · atomic ·.

If {variety} is · list · then the {variety} of {item type definition} must be either · atomic · or · union ·. If {variety} is · union · then {member type definitions} must be a list of datatype definitions. The value of {facets} consists of the set of · facet · s specified directly in the datatype definition unioned with the possibly empty set of {facets} of {base type definition}. The value of {fundamental facets} consists of the set of · fundamental facet · s and their values.

If {final} is the empty set then the type can be used in deriving other types; the explicit values restriction , list and union prevent further derivations by · restriction · , · list · and · union · respectively.

The correspondences between the properties of the information item and properties of the component are as follows:. A · derived · datatype can be · derived · from a · primitive · datatype or another · derived · datatype by one of three means: by restriction , by list or by union. A · list · datatype must be · derived · from an · atomic · or a · union · datatype, known as the · itemType · of the · list · datatype.

This yields a datatype whose · value space · is composed of finite-length sequences of values from the · value space · of the · itemType · and whose · lexical space · is composed of space-separated lists of literals of the · itemType ·. As mentioned in List datatypes §2.

regardless of the · constraining facet · s that are applicable to the · atomic · datatype that serves as the · itemType · of the · list ·. A · union · datatype can be · derived · from one or more · atomic · , · list · or other · union · datatypes, known as the · memberTypes · of that · union · datatype. As mentioned in Union datatypes §2. regardless of the · constraining facet · s that are applicable to the datatypes that participate in the · union ·.

There is a simple type definition nearly equivalent to the simple version of the ur-type definition present in every schema by definition.

It has the following properties:. Every · value space · supports the notion of equality, with the following rules:. A · partial order · has the following properties:. A · total order · has all of the properties specified above for · partial order · , plus the following property:. When {variety} is · atomic · , {value} is inherited from {value} of {base type definition}.

For all · primitive · types {value} is as specified in the table in Fundamental Facets §C. When {variety} is · list · , {value} is false. When {variety} is · union · , {value} is partial unless one of the following:. When {variety} is · atomic · , if one of · minInclusive · or · minExclusive · and one of · maxInclusive · or · maxExclusive · are among {facets} , then {value} is true ; else {value} is false. When {variety} is · list · , if · length · or both of · minLength · and · maxLength · are among {facets} , then {value} is true ; else {value} is false.

When {variety} is · union · , if {value} is true for every member of {member type definitions} and all members of {member type definitions} share a common ancestor, then {value} is true ; else {value} is false. Some · value space · s are finite, some are countably infinite while still others could conceivably be uncountably infinite although no · value space · defined by this specification is uncountable infinite. A datatype is said to have the cardinality of its · value space ·. It is sometimes useful to categorize · value space · s and hence, datatypes as to their cardinality.

There are two significant cases:. When {variety} is · atomic · and {value} of {base type definition} is finite , then {value} is finite. When {variety} is · atomic · and {value} of {base type definition} is countably infinite and either of the following conditions are true, then {value} is finite ; else {value} is countably infinite :. When {variety} is · list · , if · length · or both of · minLength · and · maxLength · are among {facets} , then {value} is finite ; else {value} is countably infinite.

When {variety} is · union · , if {value} is finite for every member of {member type definitions} , then {value} is finite ; else {value} is countably infinite. When {variety} is · union · , if {value} is true for every member of {member type definitions} , then {value} is true ; else {value} is false. The value of length · must · be a nonNegativeInteger. For string and datatypes · derived · from string , length is measured in units of character s as defined in [XML 1.

For anyURI , length is measured in units of characters as for string. For hexBinary and base64Binary and datatypes · derived · from them, length is measured in octets 8 bits of binary data. For datatypes · derived · by · list · , length is measured in number of list items.

If {fixed} is true , then types for which the current type is the {base type definition} cannot specify a value for length other than {value}. The use of · length · on datatypes · derived · from QName and NOTATION is deprecated.

Future versions of this specification may remove this facet for these datatypes. The value of minLength · must · be a nonNegativeInteger. For string and datatypes · derived · from string , minLength is measured in units of character s as defined in [XML 1.

For hexBinary and base64Binary and datatypes · derived · from them, minLength is measured in octets 8 bits of binary data. For datatypes · derived · by · list · , minLength is measured in number of list items. If {fixed} is true , then types for which the current type is the {base type definition} cannot specify a value for minLength other than {value}. The use of · minLength · on datatypes · derived · from QName and NOTATION is deprecated. The value of maxLength · must · be a nonNegativeInteger.

For string and datatypes · derived · from string , maxLength is measured in units of character s as defined in [XML 1. For hexBinary and base64Binary and datatypes · derived · from them, maxLength is measured in octets 8 bits of binary data. For datatypes · derived · by · list · , maxLength is measured in number of list items. If {fixed} is true , then types for which the current type is the {base type definition} cannot specify a value for maxLength other than {value}.

The use of · maxLength · on datatypes · derived · from QName and NOTATION is deprecated. The value of pattern · must · be a · regular expression ·. enumeration does not impose an order relation on the · value space · it creates; the value of the · ordered · property of the · derived · datatype remains that of the datatype from which it is · derived ·.

The value of whiteSpace must be one of {preserve, replace, collapse}. whiteSpace is applicable to all · atomic · and · list · datatypes. For all · atomic · datatypes other than string and types · derived · by · restriction · from it the value of whiteSpace is collapse and cannot be changed by a schema author; for string the value of whiteSpace is preserve ; for any type · derived · by · restriction · from string the value of whiteSpace can be any of the three legal values.

For all datatypes · derived · by · list · the value of whiteSpace is collapse and cannot be changed by a schema author. For all datatypes · derived · by · union · whiteSpace does not apply directly; however, the normalization behavior of · union · types is controlled by the value of whiteSpace on that one of the · memberTypes · against which the · union · is successfully validated.

If {fixed} is true , then types for which the current type is the {base type definition} cannot specify a value for whiteSpace other than {value}. The value of maxInclusive · must · be in the · value space · of the · base type ·. If {fixed} is true , then types for which the current type is the {base type definition} cannot specify a value for maxInclusive other than {value}.

The value of maxExclusive · must · be in the · value space · of the · base type · or be equal to {value} in {base type definition}. If {fixed} is true , then types for which the current type is the {base type definition} cannot specify a value for maxExclusive other than {value}. The value of minExclusive · must · be in the · value space · of the · base type · or be equal to {value} in {base type definition}. If {fixed} is true , then types for which the current type is the {base type definition} cannot specify a value for minExclusive other than {value}.

The value of minInclusive · must · be in the · value space · of the · base type ·. If {fixed} is true , then types for which the current type is the {base type definition} cannot specify a value for minInclusive other than {value}. The value of totalDigits · must · be a positiveInteger. The term totalDigits is chosen to reflect the fact that it restricts the · value space · to those values that can be represented lexically using at most totalDigits digits.

Note that it does not restrict the · lexical space · directly; a lexical representation that adds additional leading zero digits or trailing fractional zero digits is still permitted.

If {fixed} is true , then types for which the current type is the {base type definition} cannot specify a value for totalDigits other than {value}. The value of fractionDigits · must · be a nonNegativeInteger. The term fractionDigits is chosen to reflect the fact that it restricts the · value space · to those values that can be represented lexically using at most fractionDigits to the right of the decimal point.

Note that it does not restrict the · lexical space · directly; a non- · canonical lexical representation · that adds additional leading zero digits or trailing fractional zero digits is still permitted. If {fixed} is true , then types for which the current type is the {base type definition} cannot specify a value for fractionDigits other than {value}. This specification describes two levels of conformance for datatype processors.

The first is required of all processors. Support for the other will depend on the application environments for which the processor is intended. The following table shows the values of the fundamental facets for each · built-in · datatype.

The · primitive · datatypes duration , dateTime , time , date , gYearMonth , gMonthDay , gDay , gMonth and gYear use lexical formats inspired by [ISO ]. Following [ISO ] , the lexical forms of these datatypes can include only the characters 20 through 7F.

This appendix provides more detail on the ISO formats and discusses some deviations from them for the datatypes defined in this specification. The proleptic Gregorian calendar includes dates prior to the year it came into use as an ecclesiastical calendar. It should be pointed out that the datatypes described in this specification do not cover all the types of data covered by [ISO ] , nor do they support all the lexical representations for those types of data.

The allowed decimal digits are x x For the primitive datatypes dateTime , time , date , gYearMonth , gMonthDay , gDay , gMonth and gYear. these characters have the following meanings:. For all the information items indicated by the above characters, leading zeros are required where indicated. In addition to the above, certain characters are used as designators and appear as themselves in lexical formats. In the lexical format for duration the following characters are also used as designators and appear as themselves in lexical formats:.

The values of the Year, Month, Day, Hour and Minutes components are not restricted but allow an arbitrary integer. Similarly, the value of the Seconds component allows an arbitrary decimal. Thus, the lexical format for duration and datatypes derived from it does not follow the alternative format of § 5. Truncated formats are, in general, not permitted for the datatypes defined in this specification with three exceptions. The time datatype uses a truncated format for dateTime which represents an instant of time that recurs every day.

Similarly, the gMonthDay and gDay datatypes use left-truncated formats for date. The datatype gMonth uses a right and left truncated format for date. Right truncated formats are also, in general, not permitted for the datatypes defined in this specification with the following exceptions: right-truncated representations of dateTime are used as lexical representations for date , gMonth , gYear.

An optional minus sign is allowed immediately preceding, without a space, the lexical representations for duration , dateTime , date , gYearMonth , gYear. To accommodate year values greater than , more than four digits are allowed in the year representations of dateTime , date , gYearMonth , and gYear. This follows [ISO Second Edition].

The lexical representations for the datatypes date , gYearMonth , gMonthDay , gDay , gMonth and gYear permit an optional trailing time zone specificiation. Given a dateTime S and a duration D, this appendix specifies how to compute a dateTime E where E is the end of the time period with start S and duration D i. Such computations are used, for example, to determine whether a dateTime is within a specific time period.

This appendix also addresses the addition of duration s to the datatypes date , gYearMonth , gYear , gDay and gMonth , which can be viewed as a set of dateTime s. In such cases, the addition is made to the first or starting dateTime in the set. The calculation uses the notation S[year] to represent the year field of S, S[month] to represent the month field, and so on. It also depends on the following functions:. If the day is out of range, it is pinned to be within range.

Thus April 31 turns into April This latter addition can cause the year and month to change. Leap seconds are handled by the computation by treating them as overflows.

Essentially, a value of 60 seconds in S is treated as if it were a duration of 60 seconds added to S with a zero seconds field. All calculations thereafter use 60 seconds per minute. Thus the addition of either PT1M or PT60S to any dateTime will always produce the same result.

This is a special definition of addition which is designed to match common practice, and -- most importantly -- be stable over time. A definition that attempted to take leap-seconds into account would need to be constantly updated, and could not predict the results of future implementation's additions. The decision to introduce a leap second in UTC is the responsibility of the [International Earth Rotation Service IERS ].

They make periodic announcements as to when leap seconds are to be added, but this is not known more than a year in advance. For more information on leap seconds, see [U. Naval Observatory Time Service Department]. The following is the precise specification. These steps must be followed in the same order. If a field in D is not specified, it is treated as if it were zero. If a field in S is not specified, it is treated in the calculation as if it were the minimum allowed value in that field, however, after the calculation is concluded, the corresponding field in E is removed set to unspecified.

The order of addition of durations to instants is significant. For example, there are cases where:. A · regular expression · R is a sequence of characters that denote a set of strings L R.

When used to constrain a · lexical space · , a regular expression R asserts that only strings in L R are valid literals for values of that type.

These characters have special meanings in · regular expression · s, but can be escaped to form · atom · s that denote the sets of strings containing only themselves, i.

In · regular expression · s, a normal character is an atom that denotes the singleton set of strings containing only itself. Note that a · normal character · can be represented either as itself, or with a character reference. The set of strings L R denoted by a character class R contains one single-character string " c " for each character c in C R. A character class is either a · character class escape · or a · character class expression ·.

A positive character group identifies the set of characters containing all of the characters in all of the sets identified by its constituent ranges or escapes. For any · positive character group · or · negative character group · G , and any · character class expression · C , G-C is a valid · character class subtraction · , identifying the set of all characters in C G that are not also in C C.

A single XML character is a · character range · that identifies the set of characters containing only itself. All XML characters are valid character ranges, except as follows:. A · character range · · may · also be written in the form s-e , identifying the set that contains all XML characters with UCS code points greater than or equal to the code point of s , but not greater than the code point of e. The valid character class escapes are the · single character escape · s, the · multi-character escape · s, and the · category escape · s including the · block escape · s.

The following table specifies the recognized values of the "General Category" property. The following table specifies the recognized block names for more information, see the "Blocks. txt" file in [Unicode Database]. The listing below is for the benefit of readers of a printed version of this document: it collects together all the definitions which appear in the document above. Co-editor Ashok Malhotra's work on this specification from March until February was supported by IBM.

From February until May it was supported by Microsoft. The editors acknowledge the members of the XML Schema Working Group, the members of other W3C Working Groups, and industry experts in other forums who have contributed directly or indirectly to the process or content of creating this document. The Working Group is particularly grateful to Lotus Development Corp. and IBM for providing teleconferencing facilities. At the time the first edition of this specification was published, the members of the XML Schema Working Group were:.

The XML Schema Working Group has benefited in its work from the participation and contributions of a number of people not currently members of the Working Group, including in particular those named below. Affiliations given are those current at the time of their work with the WG. The lists given above pertain to the first edition. At the time work on this second edition was completed, the membership of the Working Group was:.

We note with sadness the accidental death of Mario Jeckle shortly after the completion of work on this document. In addition to those named above, several people served on the Working Group during the development of this second edition:. Biron kp. Abstract XML Schema: Datatypes is part 2 of the specification of the XML Schema language.

Status of this Document This section describes the status of this document at the time of its publication. Note: Ashok Malhotra's affiliation has changed since the completion of editorial work on this second edition. malhotra oracle.

Table of Contents 1 Introduction 1. biron kp. those governing an underlying information set; allow creation of user-defined datatypes, such as datatypes that are derived from existing datatypes and which may constrain certain of its properties e. The terms defined in the following list are used in building those definitions and in describing the actions of a datatype processor: [Definition:] for compatibility A feature of this specification included solely to ensure that schemas which use this feature remain compatible with [XML 1.

No case folding is performed. Of strings and rules in the grammar: A string matches a grammatical production if it belongs to the language generated by that production.

Conforming software · may · detect and report an error and · may · recover from it. conditions components · must · satisfy to be components at all. Largely to be found in Datatype components §4. Some but not all of these are expressed in Schema for Datatype Definitions normative §A and DTD for Datatype Definitions non-normative §B.

The · value space · of a given datatype can be defined in one of the following ways: defined axiomatically from fundamental notions intensional definition [see · primitive · ] enumerated outright extensional definition [see · enumeration · ] defined by restricting the · value space · of an already defined datatype to a particular subset with a given set of properties [see · derived · ] defined as a combination of values from one or more already defined · value space · s by a specific construction procedure [see · list · and · union · ] · value space · s have certain properties.

Note: The literals in the · lexical space · s defined in this specification have the following characteristics: Interoperability: The number of literals for each value has been kept small; for many datatypes there is a one-to-one mapping between literals and values.

This makes it easy to exchange the values between different systems. In many cases, conversion from locale-dependent representations will be required on both the originator and the recipient side, both for computer processing and for interaction with humans. Basic readability: Textual, rather than binary, literals are used. This makes hand editing, debugging, and similar activities possible. Ease of parsing and serializing: Where possible, literals correspond to those found in common programming languages and libraries.

list vs. union datatypes 2. derived datatypes 2. user-derived datatypes. union datatypes The first distinction to be made is that between · atomic · , · list · and · union · datatypes. In the above example, the value of the someElement element is not a · list · of · length · 3; rather, it is a · list · of · length · A prototypical example of a · union · type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below.

Note: A datatype which is · atomic · in this specification need not be an "atomic" datatype in any programming language used to implement this specification.

Likewise, a datatype which is a · list · in this specification need not be a "list" datatype in any programming language used to implement this specification. Furthermore, a datatype which is a · union · in this specification need not be a "union" datatype in any programming language used to implement this specification.

derived datatypes Next, we distinguish between · primitive · and · derived · datatypes. Note: A datatype which is · primitive · in this specification need not be a "primitive" datatype in any programming language used to implement this specification. Likewise, a datatype which is · derived · in this specification need not be a "derived" datatype in any programming language used to implement this specification.

user-derived datatypes [Definition:] Built-in datatypes are those which are defined in this specification, and can be either · primitive · or · derived · ; [Definition:] User-derived datatypes are those · derived · datatypes that are defined by individual schema designers.

Note: A datatype which is · built-in · in this specification need not be a "built-in" datatype in any programming language used to implement this specification. Likewise, a datatype which is · user-derived · in this specification need not be a "user-derived" datatype in any programming language used to implement this specification. maxInclusive 3. Note: Many human languages have writing systems that require child elements for control of aspects such as bidirectional formating or ruby annotation see [Ruby] and Section 8.

Thus, string , as a simple type that can contain only characters but not child elements, is often not suitable for representing text. In such situations, a complex type that allows mixed content should be considered. For more information, see Section 5. Note: As noted in ordered , the fact that this specification does not specify an · order-relation · for · string · does not preclude other applications from treating strings as being ordered. Note: All · minimally conforming · processors · must · support decimal numbers with a minimum of 18 decimal digits i.

However, · minimally conforming · processors · may · set an application-defined limit on the maximum number of decimal digits they are prepared to support, in which case that application-defined maximum number · must · be clearly documented. Note: "Equality" in this Recommendation is defined to be "identity" i. Identity must be used for the few operations that are defined in this Recommendation. Applications using any of the datatypes defined in this Recommendation may use different definitions of equality for computational purposes; [IEEE ] -based computation systems are examples.

Nothing in this Recommendation should be construed as requiring that such applications use identity as their equality relationship when computing.

Any value · incomparable · with the value used for the four bounding facets · minInclusive · , · maxInclusive · , · minExclusive · , and · maxExclusive · will be excluded from the resulting restricted · value space ·. In particular, when "NaN" is used as a facet value for a bounding facet, since no other float values are · comparable · with it, the result is a · value space · either having NaN as its only member the inclusive cases or that is empty the exclusive cases.

If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted · value space · ; to add NaN back in requires union with the NaN-only space. This datatype differs from that of [IEEE ] in that there is only one NaN and only one zero.

In particular, when "NaN" is used as a facet value for a bounding facet, since no other double values are · comparable · with it, the result is a · value space · either having NaN as its only member the inclusive cases or that is empty the exclusive cases. Note: All · minimally conforming · processors · must · support year values with a minimum of 4 digits i.

However, · minimally conforming · processors · may · set an application-defined limit on the maximum number of digits they are prepared to support in these two cases, in which case that application-defined maximum number · must · be clearly documented.

Reduced precision and truncated representations of this format are allowed provided they conform to the following: If the number of years, months, days, hours, minutes, or seconds in any expression equals zero, the number and its corresponding designator · may · be omitted.

However, at least one number and its designator · must · be present. The seconds part · may · have a decimal fraction. The designator 'T' must be absent if and only if all of the time items are absent. The designator 'P' must always be present. Days Minimum 28 59 89 Maximum 31 62 92 year, month day, hour, minute, second For example, a datatype could be defined to correspond to the [SQL] datatype Year-Month interval that required a four digit year field and a two digit month field but required all other fields to be unspecified.

Note: The date and time datatypes described in this recommendation were inspired by [ISO ]. There is no year 0, and '' is not a valid lexical representation.

Those using this 1. However, [ISO Second Edition] , which became available just as we were completing version 1. A number of external commentators have also suggested that '' be allowed, as the lexical representation for 1 BCE, which is the normal usage in astronomical contexts. It is the intention of the XML Schema Working Group to allow '' as a lexical representation in the dateTime , date , gYear , and gYearMonth datatypes in a subsequent version of this Recommendation.

Note: See the conformance note in §3. yyyy is a four-or-more digit optionally negative-signed numeral that represents the year; if more than four digits, leading zeros are prohibited, and '' is prohibited see the Note above §3.

Where there is more than one possible representation, the canonical representation is as follows: The 2-digit numeral representing the hour must not be ' 24 '; The fractional second string, if present, must not end in ' 0 '; for timezoned values, the timezone must be represented with ' Z ' All timezoned dateTime values are UTC.

The ordering between two dateTime s P and Q is defined by the following algorithm: A. Note: For most timezones, either the first moment or last moment of the day a dateTime value, always UTC will have a date portion different from that of the date itself!

However, noon of that date the midpoint of the interval in that normalized timezone will always have the same date portion as the date itself, even when that noon point in time is normalized to UTC. This type should therefore be used with caution in contexts where conversion to other calendars is desired.

Note: Because years in one calendar only rarely correspond to years in other calendars, values of this type are not, in general, convertible to simple values corresponding to years in other calendars.

Note: Because days in one calendar only rarely correspond to days in other calendars, values of this type do not, in general, have any straightforward or intuitive representation in terms of most other calendars.

Note: Because months in one calendar only rarely correspond to months in other calendars, values of this type do not, in general, have any straightforward or intuitive representation in terms of most other calendars. Note: The above definition of the lexical space is more restrictive than that given in [RFC ] as regards whitespace -- this is not an issue in practice. Any string compatible with the RFC can occur in an element or attribute validated by this type, because the · whiteSpace · facet of this type is fixed to collapse , which means that all leading and trailing whitespace will be stripped, and all internal whitespace collapsed to single space characters, before the above grammar is enforced.

Note: For some values the canonical form defined above does not conform to [RFC ] , which requires breaking with linefeeds at appropriate intervals. Note: Section 5. This is an XLink-specific requirement and is not appropriate for XML Schema, since neither the · lexical space · nor the · value space · of the anyURI type are restricted to absolute URIs. Accordingly absolutization must not be performed by schema processors as part of schema validation. Note: Each URI scheme imposes specialized syntax rules for URIs in that scheme, including restrictions on the syntax of allowed fragment identifiers.

Because it is impractical for processors to check that a value is a context-appropriate URI reference, this specification follows the lead of [RFC ] as amended by [RFC ] in this matter: such rules and restrictions are not part of type validity and are not checked by · minimally conforming · processors. Thus in practice the above definition imposes only very modest obligations on · minimally conforming · processors.

Note: The mapping between literals in the · lexical space · and values in the · value space · of QName requires a namespace declaration to be in scope for the context in which QName is used. Schema Component Constraint: enumeration facet value required for NOTATION It is an · error · for NOTATION to be used directly in a schema. Only datatypes that are · derived · from NOTATION by specifying a value for · enumeration · can be used in a schema.

Note: The · value space · of ENTITY is scoped to a specific instance document. Note: The · value space · of ENTITIES is scoped to a specific instance document. An NCName as defined by [Namespaces in XML]. Depending on the value of {variety} , further properties are defined as follows: atomic {primitive type definition} A · built-in · · primitive · datatype definition.

list {item type definition} An · atomic · or · union · simple type definition. union {member type definitions} A non-empty sequence of simple type definitions.

An annotation.

Without Javascript the regular website is not functional. To go to the noscript version Compiler Explorer click here. Source Editor Diff View Tree IDE Mode. Short Link Full Link Embed in iframe.

Cookie policy Privacy policy. Become a Patron Sponsor on GitHub Donate via PayPal Source on GitHub Mailing list Installed libraries Wiki Report an issue How it works Contact the author About the author Changelog Version tree.

Compiler Execution Only Conformance View Source Editor. CppInsights Quick-bench. Popular arguments Detailed Compiler Flags Open a new window to edit verbose compiler flags. Compile to binary. Execute the code. Intel asm syntax. Demangle identifiers. Unused labels. Library functions. Horizontal whitespace. Add new Add tool Wrap lines. Select all.

The current language or compiler does not support this tool. Filter headers. Apply clang-format. Options Dump Full Module. Demangle Symbols. Filters Hide Inconsequential Passes.

Hide Debug Info. Hide Instruction Metadata. Passes Tree Pass. RTL Pass. IPA Pass. Options Raw Dump. Slim Dump. All Options. Basic Blocks. Line Numbers. Pass Details. Pass Stats. Unique IDs. Virtual Operands. Export Export PNG Export SVG. Add compiler Libraries. Project Save. Source editor Compiler Execution only. Included files. No libs configured for this language yet. You can suggest us one at any time. Load and save editor text ×.

Examples Browser-local storage Browser-local history File system. Load from examples:. Load from browser-local storage: Overwrite Delete Save to browser-local storage. Load from browser-local history:. Something alert worthy ×.

Well, do you or not? No Yes. Enter something here ×. Cancel Ok. Compiler Explorer Settings ×. These settings control how Compiler Explorer acts for you. They are not preserved as part of shared URLs, and are persisted locally using browser local storage. Colouring Site behaviour Keybindings Editor Compilation. Site theme. Colourise lines to show how the source maps to the output.

Make all colour schemes available regardless of theme. Default language Keep page status per tab. Allow my source code to be temporarily stored for diagnostic purposes in the event of an error. Use last selected language when opening new Editors.

Show community events. Vim editor mode. Desired Font Family in editors. Enable font ligatures. Automatically insert matching brackets and parentheses. Automatically indent code reload page after changing. Highlight linked code lines on hover. Highlight linked code indefinitely. Show asm description on hover. Show quick suggestions. Use custom context menu.

Keep editor source on language change. Use spaces for indentation. Enable CodeLens features requires refresh to take effect. Compile automatically when source changes. Delay before compiling: 0. Enable formatting on compilation for supported languages.

Compile executor automatically when arguments change. Share ×. Read Only. Hide Editor Toolbars. Rename Pane ×. Close Save Changes. History ×. History Diff. Inline diff.

Libraries ×. To add a library, search for one you want and select the version in the dropdown. Or if you have favorited it before, just click the library name in the Favorites section. Libraries are installed using the conan. io package manager, except for Microsoft compilers, where vcpkg is used. Timing ×.

Brokers are filtered based on your location Malaysia. By default, this variable is disabled. Follow the text coordinates with a string. The · itemType · of NMTOKENS is NMTOKEN. Given a sequence of images all the same size, such as produced by -coalesce , replace the second and later images, with a smaller image of just the area that changed relative to the previous image.

Categories:

• Forex
• Forex Bitcoin
• Binary Options online
• Binary Options
• Forex Brokers