Description

The start-tag includes the generic identifier (infoods), whitespace, and a two-digit year; both start-tag and end-tag are required. The content is an (immediately subsidiary) <header>, an optional <dflt>, and one or more <food> elements, in that order; this list is, in principle, extensible by registration. This element and its immediate subsidiaries are structural elements.

Format

An interchange file consists of precisely one <infoods 85> element. Its immediate subsidiary elements separate the collections of data about each food from each other and from the information about the source of the file and food data. The two-digit year (85) serves to identify this interchange format as distinct from any possible future revisions. Since the system is internally extensible, such revisions are not anticipated.

Example

<infoods 85>
<header>
subsidiary elements with information about the file source
</header>
<food>
subsidiary elements with information about a food
</food>
<food>
subsidiary elements with information about another food
</food>
additional <food> elements
</infoods>

In this particular example, there is no <dflt> element.

Description

Both start-tag and end-tag are required. The content is a <sender> element followed by a <source> in that order, and both are required; this list is, in principle, extensible by registration. This element is a structural element, so its immediate (non-structural) subsidiaries all require end-tags and their generic identifiers do not end in slashes.

Format

The <header> identifies the sender of the interchange file and the source of the data within it. It has no immediate data. See <sender> and c source> for the details of the information to be included.

Example

<header>
<sender>
subsidiary elements with information about the person or organization transmitting the information
</sender>
<source>
subsidiary elements with information about the source of the food component data
</source>
</header>

Description

Both start-tag and end-tag are required. The content includes these required immediate subsidiaries (the numbers in parentheses are the page numbers on which their descriptions begin):

and these optional (but see below) immediate subsidiaries:

These lists are extensible by registration as becomes necessary. There is no immediate data; the <sender> element's immediate subsidiaries are not structural elements, and so they may appear in any order.

Format

<Sender> contains data about the transmission of this interchange file: when it was created or transmitted ( <date> ), how it should be referred to when communicating with the sender ( <sendref> ), and who sent it (all the rest). The sender may be a person or a corporate entity; in either case, the sender is the entity identified in <fullname>. The <sendref> clement specifically identifies this interchange file, not the data contained therein.

If the sender is a person, then <orgz> is optional and normally there should be no <contact/>, i.e., the sender is the contact. If the sender is an organization, then there should be no <orgz>, but a <contact/> should be supplied. A person should always be identified either as sender or contact in case there are problems with automatic transmission which must be investigated. The rest of the locating information (e.g., telephone and telex numbers) in the remaining immediate subsidiary elements applies to the human sender or contact.

The <addr/> element contains a complete mailing address, including the name, title, postal code, and country, which is duplicated or expanded in separate adjacent elements. They are included in <addr/> to ensure that they are correctly located, punctuated, abbreviated, etc., within the address; they are also separate because a file recipient may be unsure of how to extract them from the mailing address correctly.

Description

The start-tag is required; there is no corresponding end-tag. The content of <date> consists of one unformatted data item that ends when another tag is encountered.

Format

The content of <date> is unformatted data which must consist of characters making up the date the interchange file is sent. Do not use dates of the form "1/2/88" or "1-2 88"; the conventions for indicating month-first versus day-first are not adequately well known nor observed. Use the internationally recognized convention "yyyy.mm.dd": it is rarely misused, is easy to read, introduces no problems at the turn of the century, and provides an easy-to-sort data item.

Example

<date> 1988.01.02

Description

The start-tag is required; there is no corresponding end-tag. The content of <sendref> consists of one unformatted data item that ends when another tag is encountered.

Format

The content of <sendref> is unformatted data which must consist of characters making up a name or phrase by which this particular interchange file can be identified in communications to the sender. It is optionally provided by the sender and is especially useful in identifying each of several interchange files being sent to the same receiver at about the same time. This might be needed by the receiver to describe which of several files had been correctly received and for the sender then to identify (by elimination) which files had been sent but not received.

Examples

<sendref> MIT/Harvard special data set 1
<sendref> NAregional.1988.10.19.0030

The second of these should not be mistaken for an international food record identifier. Although it looks somewhat like one, its use in this element indicates that it is a reference value, for the file rather than a particular food record, supplied by the sender.

Description

The start-tag is required; there is no corresponding end-tag. The content of <fullname> consists of one unformatted data item that ends when another tag is encountered.

This element is usually used in conjunction with <fsnm>.

Format

The content of <fullname> is unformatted data which must consist of the characters of the name of the person or organization being named; if a person, it does not include any title. The names and initials of this individual may be given in any appropriate order, e.g., with the surname last for most of North America and Western Europe, with the family name first for Japan and China, and so on.

Unless the element appears as an immediate subsidiary of <ianame/>, this name must be transliterated, if necessary, into the characters of the restricted ISO 646 character set permitted for ordinary data in the interchange file. If the original name is normally written in characters that are not part of that set, it will often be desirable to provide that representation as part of an <ianame/> element.

Examples

<fullname> Joseph J. Smith
<fullname> Michele Gerard
<fullname> Massachusetts Institute of Technology
<fullname> Abdul Aziz

Description

The start-tag is required; there is no corresponding end-tag. The content of a <fsnm> consists of one unformatted data item that ends when another tag is encountered.

Format

In general, any element having an immediately subsidiary <fsnm> element will also have an immediately subsidiary <fullname> element. The content of a <fsnm> is unformatted data which must consist of the characters of the name by which the person named in the associated <fullname> element (if it names a person) is addressed.

One purpose of a separate <fsnm> element, which duplicates information in the <fullname>, is to permit proper alphabetization independently of how the full name is presented in <fullname>. Hence, this field should also be specified for organizations, and will show all or part of the <fullname> in the appropriate order for alphabetizing.

The restrictions on the characters in <fsnm> are identical to those in <fullname>

Examples

<fullname> Joseph J. Smith <fsnm> Smith
<fullname> Michele Gerard <fsnm> Gerard
<fullname> Campbell Soup Company <fsnm> Campbell's
<fullname> Hasui Kawase <fsnm> Hasui

Description

Both start-tag and end-tag are required. The content of <ianame/> consists of either a <fullname> element or an <fsnm> element, or both, followed by required <lang> and <charset> elements. The content of the <fullname> and <fsnm> elements, when used in this context, may be in any character set specified by the <lang and <charset> elements since they specify how the computer-readable characters are to be interpreted. One or more <cmt/> elements may be included.

Format

The content of <ianame/> consists of elements only; there is no immediate data. The subsidiary elements are <fullname>, but with characters in any defined language and alphabet in its content and <fsnm>, but with the same characters used for <fullname> followed by <lang> and <charset> elements. At least one of the elements <fullname> or <fsnm> must appear. <Lang> and <charset> are required, and are used as defined for <exname>.

Except in special circumstances, <ianame/> should not appear without <fullname> and <fsnm> at the same level; since many receivers of interchange files will be unable to completely process names in international alphabets, names should always be provided transliterated into the standard restricted alphabet as well as in their original alphabet.

Example

<sender>
<fullname> Agricultural Research Institute <fsnm> Agricultural
<ianame/> <fullname> Rannsóknastofnun Landbúnadarins
<lang> is <charset> 8859 1 </ianame/> </sender>

Description

The start-tag is required; there is no corresponding end-tag. The content of <orgz> consists of one unformatted data item that ends when another tag is encountered.

Format

<Orgz> should only occur as an immediate subsidiary of an element also having an immediately subsidiary <fullname>. The content of <orgz> is unformatted date which must consist of the name of the organization with which the person named in the corresponding <fullname> is associated. If the <fullname> names an organization, there should be no accompanying <orgz>.

Example

<orgz> University Food Composition Service

Description

Both start-tag and end-tag are required. The content of <contact/> identifies an individual, and normally consists of <fullname> and <fsnm> elements. If necessary, it may also contain any other elements, normally subsidiary to <sender> or <source>, that are needed to permit reaching this person efficiently: <addr/>, <country>, <postcode>, <title/>, <email/>, <phone/>, <fax/>, <telex/>, <cable/>, or <cmt/>. Normally these elements should not be repeated if the ones supplied with <sender> or <source> are adequate.

Format

<Contact/> should appear when the immediate content of <sender> or <source> identifies an organization, not a person. The content consists entirely of elements; there is no immediate data.

Example

<sender>
<date> 1990.07.04
<fullname> INFOODS Secretariat, Massachusetts Institute of Technology
<fsnm> INFOODS
<addr/> Room N52-457 <-> MIT <-> 77 Massachusetts Ave <-> Cambridge, MA 02139 <> USA </addr/>
<country> US <postcode> 02139
<phone/> +1 617 253 8004 </phone/>
<contact/>
<fullname> John C. Klensin <fsnm> Klensin
<phone/> + 1 617 253 1355 </phone/>
<email/> Klensin@MIT.EDU <net/> INET <cmt/> From BITNET/EARN also </cmt/> </net/> </email/> </contact/>
</sender>

Description

Both start-tag and end-tag are required. Successive "lines" of <addr/> are separated by the special tag <->. Each of these "lines", which need not be on separate lines of the interchange fife, consists of one unformatted data item. <Addr/> may also contain a <cmt/> element.

Format

<Addr/> is an element whose content is successive lines of a sender's mailing address, separated by the special tag <->. They must be in the proper order for use as an address; some of the lines presumably will duplicate information in the <fullname>, <orgz>, <country>, and/or <postcode> elements, which are included separately for sorting convenience and other purposes.

Example

<addr/> Dr. J. J. Smith
<-> Post Office Box 1234
<-> Anywhere, Maine 00001
<-> USA
</addr/>

Description

The start-tag is required; there is no corresponding end-tag. The content of <country> consists of either a keyword or an asterisk followed by one unformatted data item. The element ends when another tag is encountered.

Format

The content of <country> is a keyword consisting of the ISO 3166 upper case two-letter ("Alpha-2") code for the country for which the associated <addr/> is intended. It is provided as a separate field to permit easy sorting and extracting by country. If ISO 3166 does not define an appropriate two-letter code, the content of <country> consists of the asterisk "keyword" (*) followed by an unformatted data item, the complete country name-expressed in the restricted ISO 646 character set generally permitted for interchange file data. The two-letter code is to be used when it exists, as it does not have alternative spellings; this facilitates sorting and retrieval.

A current list of ISO 3166-associated country codes is available from the Secretariat. The list does change between official revisions of the Standard, so the Secretariat should be consulted if a country is not found in it.

Examples

<country> US
<country> DE
<country> TZ
<country> FJ

Description

The start-tag is required; there is no corresponding end-tag. The content of <postcode> consists of one unformatted data item that ends when another tag is encountered.

Format

<Postcode> always occurs as an immediate subsidiary of an element also having an immediately subsidiary <addr/>. The content of <postcode> consists of data characters giving the regional postal code for the associated address, in the format prescribed by that country's postal system.

Examples

<postcode> D-1000
<postcode> NG7 2RD
<postcode> 73170
<postcode> 150

Description

Both start-tag and end-tag are required. The content of <title/> consists of one unformatted data item and an optional <cmt/> element.

Format

The content of <title/> is unformatted data which must be the professional title of the sender. If the sender has more than one professional title, it should be the one most relevant to that person's relationship to the interchange file or the data therein. However, compound titles are permitted when appropriate.

Examples

<title/> Professor of Nutrition </title/>
<title/> Professor of Chemistry and Director of the Analysis Laboratory </title/>
<title/> Director, INFOODS Secretariat <cmt/> Also Principal Research Scientist, Department of Architecture, MIT </cmt/> </title/>

Description

Both start-tag and end-tag are required. The content of <email/> is in one of two forms. The first consists of two required immediate subsidiary cements, <ad/> and <net/>, and optional <cmt/> elements and is used for representing addresses on most systems. The second is specific to the address formats of the international standard "MOTIS" or "X.400" messaging systems.

Format 1

The <email/> element includes two required immediate subsidiaries, the <:ad/> and the <net/>, and an optional <cmt/>, in that order. There is no immediate data. Together, the element and its subelements specify how to reach an individual by electronic mail.

<Cmt/> is permitted both immediately subsidiary to <email/> and immediately subsidiary to <net/>. In the former context, it provides information about the user's use of the mailbox or special addressing provisions. In the latter, it provides information about how the network itself is accessed.

Format 2

The <email/> element has one required immediate subsidiary element, <x400/>, and optional <cmt/> elements, in that order. There is no immediate data. The <cmt/> element is used, as in the first format, to provide information about access to the relevant network or mail system.

Notes on Networks and Addresses

The world is gradually developing two electronic mail addressing systems, with increasingly transparent gateways between the various networks that participate in each system and, of course, gateways between the two. One of these is the "domain name system" used in the National Research Internet environment in the United States and the systems attached to or imitating it (in a mail context, these are often referred to, incorrectly, as "RFC 822 addresses"). The other is associated with the international interconnection of systems using various profiles of the CCITT "X.400" or ISO "MOTIS" protocols.

The <ad/> and <net/> elements are associated with the first of these forms. They are optimized for a style of addressing often described as "a user on a host". Prior to X.400, this was essentially the only model in use, with variations on different networks. X.400 uses a structure of named (actually tagged) identifiers, and does not match the older model well.

Gateways and similar interconnections now exist between most of the networks listed under <net/>. If known and feasible, addresses should be listed as on hosts with registered Internet Domain Names, and the "network" identified as "Inet", rather than distinguishing among the various specific networks. For example,

<email/> <ad/> jck@mitvma.mit.edu</ad/> <net/> INET </net/> </email/>

is preferred to

<email/> <ad/> jck@mitvma </ad/> <net/> BITN </net/> </email/>

although the two are, in most practice, identical. Similarly,

<email/> <ad/> infoods@mcimail.com </ad/> <net/> INET </net/> </email/>

is preferred to

<email/> <ad/> infoods </ad/> <net/> MCIML </net/> </email/>

Hosts that use the UUCP protocol and that are part of the mapping project (and no others) should use domain names (and <net/> Inet </net/>) if those names are registered, and the "host. UUCP" form with <net/> UUCP </net/> otherwise. UUCP hosts that are not part of the mapping project must provide "bang paths" from well known hosts.

Finally, X.400 electronic mailboxes that can be reached from the Internet or associated systems (including BITNET, EARN, etc.) should be specified in terms of Internet addresses, although X.400 may also be supplied if that is convenient.

Examples

<email/>
<ad/> Joe Smith <JSMITH@INFOODS.SOMEINSTITUTION.SOMENET>
</ad/>
<net/> Inet </net/>
</email/>

<email/>
<ad/> 76244,305 </ad/>
<net/> CompuS </net/>
<cmt/> telephone or telex after using; this address is rarely checked </cmt/>
</email/>

<email/> <ad/> infoods@infoods.mit.edu </ad/> <net/> Inet </net/>
<cmt/> Preferred electronic address </cmt/> </email/>
<email/>
<ad/> infoods@mcimail.com </ad/> <net/> Inet </net/>
<cmt/> Accesses different address from preferred one </cmt/> </email/>

The last example shown illustrates the use of multiple <email/> elements to include multiple electronic mail addresses for the same organization.