]>

demos_ra@hotmail.com

tsv tabular data media type This document defines Multi-Sheet Tab-Separated Values (MTSV), a text format that carries one or more sheets of tab-separated values in a single file. MTSV is TSV with one additional dimension: sheets are separated by the ASCII form feed (FF) character. A TSV file that contains no FF, and no CR other than in CRLF line breaks, is an MTSV file. This document also registers the text/prs.mtsv media type. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The tab-separated values format encodes one set of records per file. Fields are separated by a tab, and records are separated by line breaks. Both separators are ASCII format effectors . HT moves "to the next in a series of predetermined positions along the printing line", and LF moves "to the next printing line". MTSV adds FF, the format effector for the next larger unit, which moves "to the first pre-determined printing line on the next form or page". Tab gives the next field, line feed gives the next record, and form feed gives the next sheet.

Relationship to TSV MTSV keeps the separators and structure of TSV, and adds only one separator, FF, and a name for each sheet. MTSV does not carry over these restrictions of the TSV grammar:

• A field can be empty, and a record can consist of a single field, as in .
• A sheet can consist of a header with no records, or of no lines at all, as a sheet can have no rows in .

A TSV file that contains no FF, and no CR other than in CRLF line breaks, is an MTSV file ().

Out of Scope This document does not define data types, formulas, formatting, cell references, or metadata. Conversion to and from spreadsheet formats such as and is also out of scope.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The grammar in this document uses ABNF , including its core rules HTAB, LF, and CRLF. In examples, <TAB> denotes the tab character (%x09), as in , and <FF> denotes the form feed character (%x0C). Line breaks are shown as line breaks; every line shown, including the last, ends with a line break. This document uses the following terms:

field:

A text value, as defined in .

record:

A sequence of fields on one line, as defined in .

header:

The first record of a sheet, which contains the name of each field, as defined in .

sheet:

A header followed by zero or more records, or no lines at all (an empty sheet). The term matches the corresponding structure in .

sheet name:

The text that follows an FF on the same line. The first sheet of a file can be written without its FF line; its sheet name is then empty.

MTSV file:

A sequence of sheets, conforming to .

TSV file:

A file conforming to .

generator:

An implementation that writes MTSV files.

parser:

An implementation that reads MTSV files.

Data Model A field is text. A record is an ordered sequence of fields. A sheet is a header and an ordered sequence of zero or more records. Every record in a sheet has as many fields as the header of that sheet. A sheet with no lines is an empty sheet; it has neither a header nor records. An MTSV file is an ordered sequence of sheets. The order of the sheets is the order in which they appear in the file. Every sheet has a sheet name. An empty sheet name is permitted. Sheet names are not required to be unique. The lines before the first FF, if there are any, form the first sheet, written without its FF line; its sheet name is empty. A TSV file that contains no FF, and no CR other than in CRLF line breaks, is an MTSV file that consists of exactly one sheet, whose sheet name is empty.

Syntax

Character Encoding An MTSV file is text in the character set identified by the charset parameter (). If the parameter is absent, the character set is UTF-8 . The grammar below is expressed in terms of characters after decoding.

Separators MTSV uses three separators, all of which are ASCII format effectors :

Separator	Character	Separates	Source
tab	HT (%x09)	fields
line break	LF (%x0A) or CRLF (%x0D.0A)	records	,
form feed	FF (%x0C)	sheets

An FF appears only at the start of a line.

Sheet Name A sheet name is written on the line that begins with an FF, directly after the FF, and ends at the line break. A sheet name follows the same rules as a field: it cannot contain HT, LF, FF, or CR.

Grammar In addition to matching the grammar, each record in a sheet MUST have the same number of fields as the header of that sheet, as required by .

Parsers An MTSV parser MUST accept every MTSV file that conforms to . A parser MUST treat the lines before the first FF, if any, as the first sheet, with an empty sheet name, and each line that begins with an FF as the start of a new sheet. A parser MUST accept both LF and CRLF as line breaks, consistent with the default line terminators in . A parser SHOULD treat a U+FEFF character at the start of a file as an encoding signature and not as part of the first field, consistent with . A parser MAY accept input that does not conform to this document. An implementation MAY set limits on the size of files, the number of sheets, records, and fields, and the length of fields and sheet names, consistent with .

Generators An MTSV generator MUST produce MTSV files that conform to . A generator MUST end every record with a line break. A generator SHOULD encode MTSV files in UTF-8, consistent with . A generator MUST write an FF line before every sheet, including the first, so that generated files can be concatenated (). A field or sheet name that contains HT, LF, FF, or CR cannot be represented in MTSV, as with fields that contain a tab in . A generator MUST NOT write such a value. How a generator handles such values is out of scope.

Examples

Single Sheet This is the example from . It is both a TSV file and an MTSV file with one sheet, whose sheet name is empty. AgeAddress Paul231115 W Franklin Bessy the Cow5Big Farm Way Zeke45W Main St ]]>

Multiple Sheets This MTSV file contains two sheets, named "People" and "Animals". People NameAgeAddress Paul231115 W Franklin Zeke45W Main St Animals NameAgeAddress Bessy the Cow5Big Farm Way ]]>

Empty Sheet This MTSV file contains a first sheet with an empty sheet name, an empty sheet named "Empty", and a sheet named "Animals". Age Paul23 Empty Animals NameAge Bessy the Cow5 ]]>

Interoperability Considerations describes which TSV files are MTSV files. This section describes how common text processing affects MTSV files. MTSV gives structure to four characters: HT, LF, FF, and CR. These characters also have other standard properties, and text processing that acts on those properties can change the structure of an MTSV file:

Line splitting:

FF has the mandatory break class in . An application that supports only TSV can present a line that begins with an FF either as a record whose first field begins with FF, or as an empty line followed by a line that contains the sheet name.

Whitespace:

HT, LF, FF, and CR have the White_Space property in . Trimming whitespace from a line can remove an FF, which turns a sheet name into a record, or remove an HT at either end of a line, which removes empty fields. Splitting a line on runs of whitespace removes empty fields and splits fields that contain spaces.

Tab expansion:

Replacing HT with spaces removes the field structure, as it does for .

Control characters:

FF is a control character. Applications that remove or reject control characters remove sheet boundaries. does not permit FF, so an MTSV file cannot be carried as XML 1.0 character data without an additional encoding.

Line endings:

Converting between LF and CRLF does not change the structure of an MTSV file (). Converting line breaks to CR alone produces a file that does not conform to this document.

Concatenation:

Concatenating MTSV files produces an MTSV file that contains the sheets of each file, in order, only if each non-empty file ends with a line break and each non-empty file after the first begins with an FF. Otherwise, the first sheet of a later file becomes part of the last sheet of the file before it. Files written by a generator begin with an FF ().

Unchanged structure:

Printing, Unicode normalization, and conversion between character sets do not change the structure of an MTSV file.

Spreadsheets:

Spreadsheet applications apply their own rules to sheet names, such as uniqueness and length, and to data types and sizes. These rules are outside the scope of this document.

IANA Considerations

Media Type Registration This document registers the text/prs.mtsv media type in the personal tree, according to , using the template in .

Type name:

text

Subtype name:

prs.mtsv

Required parameters:

N/A

Optional parameters:

charset. MTSV has no in-band charset information, so a default is needed; if charset is absent, UTF-8 is assumed, as specifies for text subtypes that define a default.

Encoding considerations:

8bit. As per , this media type uses CRLF to denote line breaks in transport. Implementations need to be aware that files often use LF alone.

Security considerations:

See .

Interoperability considerations:

See .

Published specification:

This document.

Applications that use this media type:

Applications that store or exchange multiple sheets of tabular data as text.

Fragment identifier considerations:

N/A

Additional information:

Deprecated alias names for this type:

N/A

Magic number(s):

N/A

File extension(s):

.mtsv

Macintosh file type code(s):

N/A

Person & email address to contact for further information:

Demos Ra (demos_ra@hotmail.com)

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

Demos Ra

Change controller:

Demos Ra

Files written by a generator begin with FF (%x0C).

Internationalization Considerations This section collects the internationalization decisions of this document, as recommends. HT, LF, CRLF, and FF are protocol elements. Fields and sheet names are text (), as requires a protocol to distinguish. An MTSV file carries no in-band charset information. The charset parameter of the media type identifies the charset (), and UTF-8 is assumed when that parameter is absent (), so that a stored file remains readable without it, as advises. Any other charset is one registered in the IANA charset registry, as requires. Sheet names are internationalized. A sheet name is text and follows the same rules as a field (); it is not a US-ASCII identifier. requires a document to state this. MTSV carries no language information. This document leaves language to the enclosing protocol or to separate metadata such as , which permits where the responsibility belongs to another layer.

Security Considerations MTSV files are text and contain no executable content. lists no security considerations. Applications that import MTSV files into spreadsheets can interpret fields that begin with characters such as "=", "+", "-", or "@" as formulas. Such applications need to treat imported fields as data. Sheet names can contain control characters. Applications that display sheet names need to take care that such characters do not mislead users. Parsers that do not set limits () can exhaust resources when reading large files or files with very many sheets.

References Normative References ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. University of Minnesota Internet Gopher Team n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". This memo provides information for the Internet community. This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. W3C Unicode Consortium n.d. Unicode Consortium n.d. W3C OASIS ISO/IEC

Change Log

draft-demosra-mtsv-01:

Gave every sheet a sheet name: the lines before the first FF form a first sheet whose sheet name is empty, and the term "unnamed sheet" is removed. Required generators to write an FF line before every sheet, and removed the rule on a first field that begins with U+FEFF, which that makes unnecessary. Used "N/A" in the registration template, as Section 5.6 of RFC 6838 asks.

draft-demosra-mtsv-00:

Replaces draft-demos-ra-mtsv-00, renamed so that the author component contains no hyphen. Replaced the byte order mark rules with a parser rule that follows Section 6 of RFC 3629, and stated that a first field that begins with U+FEFF cannot be represented. Removed the rule on a final record without a line break, which the rule on non-conforming input already covers. Cited CSVW as the source of LF and CRLF line breaks. Added an Internationalization Considerations section, and placed the IANA, Internationalization, and Security Considerations sections in the order that Section 4 of RFC 7322 recommends.

draft-demos-ra-mtsv-00:

Initial version.