Form Entity Name Entity Id Definition Data Code Table Data: Fill & Download for Free

The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells.Each table may have an associated caption (see theCAPTIONelement) that provides a short description of the table's purpose. A longer description may also be provided (via thesummaryattribute) for the benefit of people using speech or Braille-based user agents.Table rows may be grouped into a head, foot, and body sections, (via theTHEAD,TFOOTandTBODYelements, respectively). Row groups convey additional structural information and may be rendered by user agents in ways that emphasize this structure. User agents may exploit the head/body/foot division to support scrolling of body sections independently of the head and foot sections. When long tables are printed, the head and foot information may be repeated on each page that contains table data.Authors may also group columns to provide additional structural information that may be exploited by user agents. Furthermore, authors may declare column properties at the start of a table definition (via theCOLGROUPandCOLelements) in a way that enables user agents to render the table incrementally rather than having to wait for all the table data to arrive before rendering.Table cells may either contain "header" information (see theTHelement) or "data" (see theTDelement). Cells may span multiple rows and columns. The HTML 4 table model allows authors to label each cell so that non-visual user agents may more easily communicate heading information about the cell to the user. Not only do these mechanisms greatly assist users with visual disabilities, they make it possible for multi-modal wireless browsers with limited display capabilities (e.g., Web-enabled pagers and phones) to handle tables.Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.Note. This specification includes more detailed information about tables in sections on table design rationale and implementation issues.Here's a simple table that illustrates some of the features of the HTML table model. The following table definition:<TABLE border="1"  summary="This table gives some statistics about fruit  flies: average height and weight, and percentage  with red eyes (for both males and females)."> <CAPTION><EM>A test table with merged cells</EM></CAPTION> <TR><TH rowspan="2"><TH colspan="2">Average  <TH rowspan="2">Red<BR>eyes <TR><TH>height<TH>weight <TR><TH>Males<TD>1.9<TD>0.003<TD>40% <TR><TH>Females<TD>1.7<TD>0.002<TD>43% </TABLE> might be rendered something like this on a tty device: A test table with merged cells  /-----------------------------------------\  | | Average | Red |  | |-------------------| eyes |  | | height | weight | |  |-----------------------------------------|  | Males | 1.9 | 0.003 | 40% |  |-----------------------------------------|  | Females | 1.7 | 0.002 | 43% |  \-----------------------------------------/ or like this by a graphical user agent:11.2 Elements for constructing tables11.2.1 TheTABLEelement<!ELEMENT TABLE - -  (CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)> <!ATTLIST TABLE -- table element --  %attrs; -- %coreattrs, %i18n, %events --  summary %Text; #IMPLIED -- purpose/structure for speech output--  width %Length; #IMPLIED -- table width --  border %Pixels; #IMPLIED -- controls frame width around table --  frame %TFrame; #IMPLIED -- which parts of frame to render --  rules %TRules; #IMPLIED -- rulings between rows and cols --  cellspacing %Length; #IMPLIED -- spacing between cells --  cellpadding %Length; #IMPLIED -- spacing within cells --  > Start tag: required, End tag: requiredAttribute definitionssummary= text [CS]This attribute provides a summary of the table's purpose and structure for user agents rendering to non-visual media such as speech and Braille.align=left|center|right[CI]Deprecated. This attribute specifies the position of the table with respect to the document. Permitted values:left: The table is to the left of the document.center: The table is to the center of the document.right: The table is to the right of the document.width= length [CN]This attribute specifies the desired width of the entire table and is intended for visual user agents. When the value is a percentage value, the value is relative to the user agent's available horizontal space. In the absence of any width specification, table width is determined by the user agent.Attributes defined elsewhereid, class (document-wide identifiers)lang (language information), dir (text direction)title (element title)style (inline style information )onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events)bgcolor (background color)frame, rules, border (borders and rules)cellspacing, cellpadding (cell margins)TheTABLEelement contains all other elements that specify caption, rows, content, and formatting.The following informative list describes what operations user agents may carry out when rendering a table:Make the table summary available to the user. Authors should provide a summary of a table's content and structure so that people using non-visual user agents may better understand it.Render the caption, if one is defined.Render the table header, if one is specified. Render the table footer, if one is specified. User agents must know where to render the header and footer. For instance, if the output medium is paged, user agents may put the header at the top of each page and the footer at the bottom. Similarly, if the user agent provides a mechanism to scroll the rows, the header may appear at the top of the scrolled area and the footer at the bottom.Calculate the number of columns in the table. Note that the number of rows in a table is equal to the number of TR elements contained by the TABLE element.Group the columns according to any column group specifications.Render the cells, row by row and grouped in appropriate columns, between the header and footer. Visual user agents should format the table according to HTML attributes and style sheet specification.The HTML table model has been designed so that, with author assistance, user agents may render tables incrementally (i.e., as table rows arrive) rather than having to wait for all the data before beginning to render.In order for a user agent to format a table in one pass, authors must tell the user agent:The number of columns in the table. Please consult the section on calculating the number of columns in a table for details on how to supply this information.The widths of these columns. Please consult the section on calculating the width of columns for details on how to supply this information.More precisely, a user agent may render a table in a single pass when the column widths are specified using a combination ofCOLGROUPandCOLelements. If any of the columns are specified in relative or percentage terms (see the section on calculating the width of columns), authors must also specify the width of the table itself.Table directionalityThe directionality of a table is either the inherited directionality (the default is left-to-right) or that specified by thedirattribute for theTABLEelement.For a left-to-right table, column zero is on the left side and row zero is at the top. For a right-to-left table, column zero is on the right side and row zero is at the top.When a user agent allots extra cells to a row (see the section on calculating the number of columns in a table), extra row cells are added to the right of the table for left-to-right tables and to the left side for right-to-left tables.Note thatTABLEis the only element on whichdirreverses the visual order of the columns; a single table row (TR) or a group of columns (COLGROUP) cannot be independently reversed.When set for theTABLEelement, thedirattribute also affects the direction of text within table cells (since thedirattribute is inherited by block-level elements).To specify a right-to-left table, set thedirattribute as follows:<TABLE dir="RTL"> ...the rest of the table... </TABLE> The direction of text in individual cells can be changed by setting thedirattribute in an element that defines the cell. Please consult the section on bidirectional text for more information on text direction issues.11.2.2 Table Captions: TheCAPTIONelement<!ELEMENT CAPTION - - (%inline;)* -- table caption -->  <!ATTLIST CAPTION  %attrs; -- %coreattrs, %i18n, %events --  > Start tag: required, End tag: requiredAttribute definitionsalign=top|bottom|left|right[CI]Deprecated. For visual user agents, this attribute specifies the position of the caption with respect to the table. Possible values:top: The caption is at the top of the table. This is the default value.bottom: The caption is at the bottom of the table.left: The caption is at the left of the table.right: The caption is at the right of the table.Attributes defined elsewhereid, class (document-wide identifiers)lang (language information), dir (text direction)title (element title)style (inline style information )onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events )When present, theCAPTIONelement's text should describe the nature of the table. TheCAPTIONelement is only permitted immediately after theTABLEstart tag. ATABLEelement may only contain oneCAPTIONelement.Visual user agents allow sighted people to quickly grasp the structure of the table from the headings as well as the caption. A consequence of this is that captions will often be inadequate as a summary of the purpose and structure of the table from the perspective of people relying on non-visual user agents.Authors should therefore take care to provide additional information summarizing the purpose and structure of the table using thesummaryattribute of theTABLEelement. This is especially important for tables without captions. Examples below illustrate the use of thesummaryattribute.Visual user agents should avoid clipping any part of the table including the caption, unless a means is provided to access all parts, e.g., by horizontal or vertical scrolling. We recommend that the caption text be wrapped to the same width as the table. (See also the section on recommended layout algorithms.)11.2.3 Row groups: theTHEAD,TFOOT, andTBODYelements<!ELEMENT THEAD - O (TR)+ -- table header --> <!ELEMENT TFOOT - O (TR)+ -- table footer --> Start tag: required, End tag: optional<!ELEMENT TBODY O O (TR)+ -- table body --> Start tag: optional, End tag: optional<!ATTLIST (THEAD|TBODY|TFOOT) -- table section --  %attrs; -- %coreattrs, %i18n, %events --  %cellhalign; -- horizontal alignment in cells --  %cellvalign; -- vertical alignment in cells --  > Attributes defined elsewhereid, class (document-wide identifiers)lang (language information), dir (text direction)title (element title)style (inline style information )onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events )align, char, charoff, valign (cell alignment)Table rows may be grouped into a table head, table foot, and one or more table body sections, using theTHEAD,TFOOTandTBODYelements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.The table head and table foot should contain information about the table's columns. The table body should contain rows of table data.When present, eachTHEAD,TFOOT, andTBODYcontains a row group. Each row group must contain at least one row, defined by theTRelement.This example illustrates the order and structure of table heads, feet, and bodies.<TABLE> <THEAD>  <TR> ...header information... </THEAD> <TFOOT>  <TR> ...footer information... </TFOOT> <TBODY>  <TR> ...first row of block one data...  <TR> ...second row of block one data... </TBODY> <TBODY>  <TR> ...first row of block two data...  <TR> ...second row of block two data...  <TR> ...third row of block two data... </TBODY> </TABLE> TFOOTmust appear beforeTBODYwithin aTABLEdefinition so that user agents can render the foot before receiving all of the (potentially numerous) rows of data. The following summarizes which tags are required and which may be omitted:The TBODY start tag is always required except when the table contains only one table body and no table head or foot sections. The TBODY end tag may always be safely omitted.The start tags for THEAD and TFOOT are required when the table head and foot sections are present respectively, but the corresponding end tags may always be safely omitted.Conforming user agent parsers must obey these rules for reasons of backward compatibility.The table of the previous example could be shortened by removing certain end tags, as in:<TABLE> <THEAD>  <TR> ...header information... <TFOOT>  <TR> ...footer information... <TBODY>  <TR> ...first row of block one data...  <TR> ...second row of block one data... <TBODY>  <TR> ...first row of block two data...  <TR> ...second row of block two data...  <TR> ...third row of block two data... </TABLE> TheTHEAD,TFOOT, andTBODYsections must contain the same number of columns.11.2.4 Column groups: theCOLGROUPandCOLelementsColumn groups allow authors to create structural divisions within a table. Authors may highlight this structure through style sheets or HTML attributes (e.g., therulesattribute for theTABLEelement). For an example of the visual presentation of column groups, please consult the sample table.A table may either contain a single implicit column group (noCOLGROUPelement delimits the columns) or any number of explicit column groups (each delimited by an instance of theCOLGROUPelement).TheCOLelement allows authors to share attributes among several columns without implying any structural grouping. The "span" of theCOLelement is the number of columns that will share the element's attributes.TheCOLGROUPelement<!ELEMENT COLGROUP - O (COL)* -- table column group --> <!ATTLIST COLGROUP  %attrs; -- %coreattrs, %i18n, %events --  span NUMBER 1 -- default number of columns in group --  width %MultiLength; #IMPLIED -- default width for enclosed COLs --  %cellhalign; -- horizontal alignment in cells --  %cellvalign; -- vertical alignment in cells --  > Start tag: required, End tag: optionalAttribute definitionsspan= number [CN]This attribute, which must be an integer > 0, specifies the number of columns in a column group. Values mean the following:In the absence of a span attribute, each COLGROUP defines a column group containing one column.If the span attribute is set to N > 0, the current COLGROUP element defines a column group containing N columns.User agents must ignore this attribute if theCOLGROUPelement contains one or moreCOLelements.width= multi-length [CN]This attribute specifies a default width for each column in the current column group. In addition to the standard pixel, percentage, and relative values, this attribute allows the special form "0*" (zero asterisk) which means that the width of the each column in the group should be the minimum width necessary to hold the column's contents. This implies that a column's entire contents must be known before its width may be correctly computed. Authors should be aware that specifying "0*" will prevent visual user agents from rendering a table incrementally.This attribute is overridden for any column in the column group whosewidthis specified via aCOLelement.Attributes defined elsewhereid, class (document-wide identifiers)lang (language information), dir (text direction)title (element title)style (inline style information )onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events )align, char, charoff, valign (cell alignment)TheCOLGROUPelement creates an explicit column group. The number of columns in the column group may be specified in two, mutually exclusive ways:The element's span attribute (default value 1) specifies the number of columns in the group.Each COL element in the COLGROUP represents one or more columns in the group.The advantage of using thespanattribute is that authors may group together information about column widths. Thus, if a table contains forty columns, all of which have a width of 20 pixels, it is easier to write: <COLGROUP span="40" width="20">  </COLGROUP> than: <COLGROUP>  <COL width="20">  <COL width="20">  ...a total of forty COL elements...  </COLGROUP> When it is necessary to single out a column (e.g., for style information, to specify width information, etc.) within a group, authors must identify that column with aCOLelement. Thus, to apply special style information to the last column of the previous table, we single it out as follows: <COLGROUP width="20">  <COL span="39">  <COL id="format-me-specially">  </COLGROUP> Thewidthattribute of theCOLGROUPelement is inherited by all 40 columns. The firstCOLelement refers to the first 39 columns (doing nothing special to them) and the second one assigns anidvalue to the fortieth column so that style sheets may refer to it.The table in the following example contains two column groups. The first column group contains 10 columns and the second contains 5 columns. The default width for each column in the first column group is 50 pixels. The width of each column in the second column group will be the minimum required for that column.<TABLE> <COLGROUP span="10" width="50"> <COLGROUP span="5" width="0*"> <THEAD> <TR><TD> ... </TABLE> TheCOLelement<!ELEMENT COL - O EMPTY -- table column --> <!ATTLIST COL -- column groups and properties --  %attrs; -- %coreattrs, %i18n, %events --  span NUMBER 1 -- COL attributes affect N columns --  width %MultiLength; #IMPLIED -- column width specification --  %cellhalign; -- horizontal alignment in cells --  %cellvalign; -- vertical alignment in cells --  > Start tag: required, End tag: forbiddenAttribute definitionsspan= number [CN]This attribute, whose value must be an integer > 0, specifies the number of columns "spanned" by theCOLelement; theCOLelement shares its attributes with all the columns it spans. The default value for this attribute is 1 (i.e., theCOLelement refers to a single column). If thespanattribute is set to N > 1, the currentCOLelement shares its attributes with the next N-1 columns.width= multi-length [CN]This attribute specifies a default width for each column spanned by the currentCOLelement. It has the same meaning as thewidthattribute for theCOLGROUPelement and overrides it.Attributes defined elsewhereid, class (document-wide identifiers)lang (language information), dir (text direction)title (element title)style (inline style information )onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events )align, char, charoff, valign (cell alignment)TheCOLelement allows authors to group together attribute specifications for table columns. TheCOLdoes not group columns together structurally -- that is the role of theCOLGROUPelement.COLelements are empty and serve only as a support for attributes. They may appear inside or outside an explicit column group (i.e.,COLGROUPelement).Thewidthattribute forCOLrefers to the width of each column in the element's span.Calculating the number of columns in a tableThere are two ways to determine the number of columns in a table (in order of precedence):If the TABLE element contains any COLGROUP or COL elements, user agents should calculate the number of columns by summing the following:For each COL element, take the value of its span attribute (default value 1).For each COLGROUP element containing at least one COL element, ignore the span attribute for the COLGROUP element. For each COL element, perform the calculation of step 1.For each empty COLGROUP element, take the value of its span attribute (default value 1).Otherwise, if the TABLE element contains no COLGROUP or COL elements, user agents should base the number of columns on what is required by the rows. The number of columns is equal to the number of columns required by the row with the most columns, including cells that span multiple columns. For any row that has fewer than this number of columns, the end of that row should be padded with empty cells. The "end" of a row depends on the table directionality.It is an error if a table containsCOLGROUPorCOLelements and the two calculations do not result in the same number of columns.Once the user agent has calculated the number of columns in the table, it may group them into column groups.For example, for each of the following tables, the two column calculation methods should result in three columns. The first three tables may be rendered incrementally.<TABLE> <COLGROUP span="3"></COLGROUP> <TR><TD> ... ...rows... </TABLE>  <TABLE> <COLGROUP> <COL> <COL span="2"> </COLGROUP> <TR><TD> ... ...rows... </TABLE>  <TABLE> <COLGROUP> <COL> </COLGROUP> <COLGROUP span="2"> <TR><TD> ... ...rows... </TABLE>  <TABLE> <TR>  <TD><TD><TD> </TR> </TABLE> Calculating the width of columnsAuthors may specify column widths in three ways:FixedA fixed width specification is given in pixels (e.g.,width="30"). A fixed-width specification enables incremental rendering.PercentageA percentage specification (e.g.,width="20%") is based on the percentage of the horizontal space available to the table (between the current left and right margins, including floats). Note that this space does not depend on the table itself, and thus percentage specifications enable incremental rendering.ProportionalProportional specifications (e.g.,width="3*") refer to portions of the horizontal space required by a table. If the table width is given a fixed value via thewidthattribute of theTABLEelement, user agents may render the table incrementally even with proportional columns.However, if the table does not have a fixed width, user agents must receive all table data before they can determine the horizontal space required by the table. Only then may this space be allotted to proportional columns.If an author specifies no width information for a column, a user agent may not be able to incrementally format the table since it must wait for the entire column of data to arrive in order to allot an appropriate width.If column widths prove to be too narrow for the contents of a particular table cell, user agents may choose to reflow the table.The table in this example contains six columns. The first one does not belong to an explicit column group. The next three belong to the first explicit column group and the last two belong to the second explicit column group. This table cannot be formatted incrementally since it contains proportional column width specifications and no value for thewidthattribute for theTABLEelement.Once the (visual) user agent has received the table's data: the available horizontal space will be alloted by the user agent as follows: First the user agent will allot 30 pixels to columns one and two. Then, the minimal space required for the third column will be reserved. The remaining horizontal space will be divided into six equal portions (since 2* + 1* + 3* = 6 portions). Column four (2*) will receive two of these portions, column five (1*) will receive one, and column six (3*) will receive three.  <TABLE> <COLGROUP>  <COL width="30"> <COLGROUP>  <COL width="30">  <COL width="0*">  <COL width="2*"> <COLGROUP align="center">  <COL width="1*">  <COL width="3*" align="char" char=":"> <THEAD> <TR><TD> ... ...rows... </TABLE> We have set the value of thealignattribute in the third column group to "center". All cells in every column in this group will inherit this value, but may override it. In fact, the finalCOLdoes just that, by specifying that every cell in the column it governs will be aligned along the ":" character.In the following table, the column width specifications allow the user agent to format the table incrementally:  <TABLE width="200"> <COLGROUP span="10" width="15"> <COLGROUP width="*">  <COL id="penultimate-column">  <COL id="last-column"> <THEAD> <TR><TD> ... ...rows... </TABLE> The first ten columns will be 15 pixels wide each. The last two columns will each receive half of the remaining 50 pixels. Note that theCOLelements appear only so that anidvalue may be specified for the last two columns.Note. Although thewidthattribute on theTABLEelement is not deprecated, authors are encouraged to use style sheets to specify table widths.11.2.5 Table rows: TheTRelement<!ELEMENT TR - O (TH|TD)+ -- table row --> <!ATTLIST TR -- table row --  %attrs; -- %coreattrs, %i18n, %events --  %cellhalign; -- horizontal alignment in cells --  %cellvalign; -- vertical alignment in cells --  > Start tag: required, End tag: optionalAttributes defined elsewhereid, class (document-wide identifiers)lang (language information), dir (text direction)title (element title)style (inline style information )onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events )bgcolor (background color)align, char, charoff, valign (cell alignment)TheTRelements acts as a container for a row of table cells. The end tag may be omitted.This sample table contains three rows, each begun by theTRelement:<TABLE summary="This table charts the number of cups  of coffee consumed by each senator, the type   of coffee (decaf or regular), and whether   taken with sugar."> <CAPTION>Cups of coffee consumed by each senator</CAPTION> <TR> ...A header row... <TR> ...First row of data... <TR> ...Second row of data... ...the rest of the table... </TABLE> 11.2.6 Table cells: TheTHandTDelements<!ELEMENT (TH|TD) - O (%flow;)* -- table header cell, table data cell-->  <!-- Scope is simpler than headers attribute for common tables --> <!ENTITY % Scope "(row|col|rowgroup|colgroup)">  <!-- TH is for headers, TD for data, but for cells acting as both use TD --> <!ATTLIST (TH|TD) -- header or data cell --  %attrs; -- %coreattrs, %i18n, %events --  abbr %Text; #IMPLIED -- abbreviation for header cell --  axis CDATA #IMPLIED -- comma-separated list of related headers--  headers IDREFS #IMPLIED -- list of id's for header cells --  scope %Scope; #IMPLIED -- scope covered by header cells --  rowspan NUMBER 1 -- number of rows spanned by cell --  colspan NUMBER 1 -- number of cols spanned by cell --  %cellhalign; -- horizontal alignment in cells --  %cellvalign; -- vertical alignment in cells --  > Start tag: required, End tag: optionalAttribute definitionsheaders= idrefs [CS]This attribute specifies the list of header cells that provide header information for the current data cell. The value of this attribute is a space-separated list of cell names; those cells must be named by setting theiridattribute. Authors generally use theheadersattribute to help non-visual user agents render header information about data cells (e.g., header information is spoken prior to the cell data), but the attribute may also be used in conjunction with style sheets. See also thescopeattribute.scope= scope-name [CI]This attribute specifies the set of data cells for which the current header cell provides header information. This attribute may be used in place of theheadersattribute, particularly for simple tables. When specified, this attribute must have one of the following values:row: The current cell provides header information for the rest of the row that contains it (see also the section on table directionality).col: The current cell provides header information for the rest of the column that contains it.rowgroup: The header cell provides header information for the rest of the row group that contains it.colgroup: The header cell provides header information for the rest of the column group that contains it.abbr= text [CS]This attribute should be used to provide an abbreviated form of the cell's content, and may be rendered by user agents when appropriate in place of the cell's content. Abbreviated names should be short since user agents may render them repeatedly. For instance, speech synthesizers may render the abbreviated headers relating to a particular cell before rendering that cell's content.axis= cdata [CI]This attribute may be used to place a cell into conceptual categories that can be considered to form axes in an n-dimensional space. User agents may give users access to these categories (e.g., the user may query the user agent for all cells that belong to certain categories, the user agent may present a table in the form of a table of contents, etc.). Please consult the section on categorizing cells for more information. The value of this attribute is a comma-separated list of category names.rowspan= number [CN]This attribute specifies the number of rows spanned by the current cell. The default value of this attribute is one ("1"). The value zero ("0") means that the cell spans all rows from the current row to the last row of the table section (THEAD,TBODY, orTFOOT) in which the cell is defined.colspan= number [CN]This attribute specifies the number of columns spanned by the current cell. The default value of this attribute is one ("1"). The value zero ("0") means that the cell spans all columns from the current column to the last column of the column group (COLGROUP) in which the cell is defined.nowrap[CI]Deprecated. When present, this boolean attribute tells visual user agents to disable automatic text wrapping for this cell. Style sheets should be used instead of this attribute to achieve wrapping effects. Note. if used carelessly, this attribute may result in excessively wide cells.width= length [CN]Deprecated. This attribute supplies user agents with a recommended cell width.height= length [CN]Deprecated. This attribute supplies user agents with a recommended cell height.Attributes defined elsewhereid, class (document-wide identifiers)lang (language information), dir (text direction)title (element title)style (inline style information )onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup (intrinsic events )bgcolor (background color)align, char, charoff, valign (cell alignment)Table cells may contain two types of information: header information and data. This distinction enables user agents to render header and data cells distinctly, even in the absence of style sheets. For example, visual user agents may present header cell text with a bold font. Speech synthesizers may render header information with a distinct voice inflection.TheTHelement defines a cell that contains header information. User agents have two pieces of header information available: the contents of theTHelement and the value of theabbrattribute. User agents must render either the contents of the cell or the value of theabbrattribute. For visual media, the latter may be appropriate when there is insufficient space to render the full contents of the cell. For non-visual mediaabbrmay be used as an abbreviation for table headers when these are rendered along with the contents of the cells to which they apply.Theheadersandscopeattributes also allow authors to help non-visual user agents process header information. Please consult the section on labeling cells for non-visual user agents for information and examples.TheTDelement defines a cell that contains data.Cells may be empty (i.e., contain no data).For example, the following table contains four columns of data, each headed by a column description.<TABLE summary="This table charts the number of cups  of coffee consumed by each senator, the type   of coffee (decaf or regular), and whether   taken with sugar."> <CAPTION>Cups of coffee consumed by each senator</CAPTION> <TR>  <TH>Name</TH>  <TH>Cups</TH>  <TH>Type of Coffee</TH>  <TH>Sugar?</TH> <TR>  <TD>T. Sexton</TD>  <TD>10</TD>  <TD>Espresso</TD>  <TD>No</TD> <TR>  <TD>J. Dinnen</TD>  <TD>5</TD>  <TD>Decaf</TD>  <TD>Yes</TD> </TABLE> A user agent rendering to a tty device might display this as follows:Name Cups Type of Coffee Sugar? T. Sexton 10 Espresso No J. Dinnen 5 Decaf Yes Cells that span several rows or columnsCells may span several rows or columns. The number of rows or columns spanned by a cell is set by therowspanandcolspanattributes for theTHandTDelements.In this table definition, we specify that the cell in row four, column two should span a total of three columns, including the current column.<TABLE border="1"> <CAPTION>Cups of coffee consumed by each senator</CAPTION> <TR><TH>Name<TH>Cups<TH>Type of Coffee<TH>Sugar? <TR><TD>T. Sexton<TD>10<TD>Espresso<TD>No <TR><TD>J. Dinnen<TD>5<TD>Decaf<TD>Yes <TR><TD>A. Soria<TD colspan="3"><em>Not available</em> </TABLE> This table might be rendered on a tty device by a visual user agent as follows:Cups of coffee consumed by each senator  --------------------------------------  | Name |Cups|Type of Coffee|Sugar?|  --------------------------------------  |T. Sexton|10 |Espresso |No |  --------------------------------------  |J. Dinnen|5 |Decaf |Yes |  --------------------------------------  |A. Soria |Not available |  -------------------------------------- The next example illustrates (with the help of table borders) how cell definitions that span more than one row or column affect the definition of later cells. Consider the following table definition:<TABLE border="1"> <TR><TD>1 <TD rowspan="2">2 <TD>3 <TR><TD>4 <TD>6 <TR><TD>7 <TD>8 <TD>9 </TABLE> As cell "2" spans the first and second rows, the definition of the second row will take it into account. Thus, the secondTDin row two actually defines the row's third cell. Visually, the table might be rendered to a tty device as:------------- | 1 | 2 | 3 |  ----| |---- | 4 | | 6 | ----|---|---- | 7 | 8 | 9 | ------------- while a graphical user agent might render this as:Note that if theTDdefining cell "6" had been omitted, an extra empty cell would have been added by the user agent to complete the row.Similarly, in the following table definition:<TABLE border="1"> <TR><TD>1 <TD>2 <TD>3 <TR><TD colspan="2">4 <TD>6 <TR><TD>7 <TD>8 <TD>9 </TABLE> cell "4" spans two columns, so the secondTDin the row actually defines the third cell ("6"):------------- | 1 | 2 | 3 |  --------|---- | 4 | 6 | --------|---- | 7 | 8 | 9 | ------------- A graphical user agent might render this as:Defining overlapping cells is an error. User agents may vary in how they handle this error (e.g., rendering may vary).The following illegal example illustrates how one might create overlapping cells. In this table, cell "5" spans two rows and cell "7" spans two columns, so there is overlap in the cell between "7" and "9":<TABLE border="1"> <TR><TD>1 <TD>2 <TD>3 <TR><TD>4 <TD rowspan="2">5 <TD>6 <TR><TD colspan="2">7 <TD>9 </TABLE> 11.3 Table formatting by visual user agentsNote. The following sections describe the HTML table attributes that concern visual formatting. When this specification was first published in 1997, [CSS1] did not offer mechanisms to control all aspects of visual table formatting. Since then, [CSS2] has added properties to allow visual formatting of tables.HTML 4 includes mechanisms to control:border styleshorizontal and vertical alignment of cell contentsand cell margins11.3.1 Borders and rulesThe following attributes affect a table's external frame and internal rules.Attribute definitionsframe=void|above|below|hsides|lhs|rhs|vsides|box|border[CI]This attribute specifies which sides of the frame surrounding a table will be visible. Possible values:void: No sides. This is the default value.above: The top side only.below: The bottom side only.hsides: The top and bottom sides only.vsides: The right and left sides only.lhs: The left-hand side only.rhs: The right-hand side only.box: All four sides.border: All four sides.rules=none|groups|rows|cols|all[CI]This attribute specifies which rules will appear between cells within a table. The rendering of rules is user agent dependent. Possible values:none: No rules. This is the default value.groups: Rules will appear between row groups (see THEAD, TFOOT, and TBODY) and column groups (see COLGROUP and COL) only.rows: Rules will appear between rows only.cols: Rules will appear between columns only.all: Rules will appear between all rows and columns.border= pixels [CN]This attributes specifies the width (in pixels only) of the frame around a table (see the Note below for more information about this attribute).To help distinguish the cells of a table, we can set theborderattribute of theTABLEelement. Consider a previous example:<TABLE border="1"   summary="This table charts the number of cups  of coffee consumed by each senator, the type   of coffee (decaf or regular), and whether   taken with sugar."> <CAPTION>Cups of coffee consumed by each senator</CAPTION> <TR>  <TH>Name</TH>  <TH>Cups</TH>  <TH>Type of Coffee</TH>  <TH>Sugar?</TH> <TR>  <TD>T. Sexton</TD>  <TD>10</TD>  <TD>Espresso</TD>  <TD>No</TD> <TR>  <TD>J. Dinnen</TD>  <TD>5</TD>  <TD>Decaf</TD>  <TD>Yes</TD> </TABLE> In the following example, the user agent should show borders five pixels thick on the left-hand and right-hand sides of the table, with rules drawn between each column.<TABLE border="5" frame="vsides" rules="cols"> <TR> <TD>1 <TD>2 <TD>3 <TR> <TD>4 <TD>5 <TD>6 <TR> <TD>7 <TD>8 <TD>9 </TABLE> The following settings should be observed by user agents for backwards compatibility.Setting border="0" implies frame="void" and, unless otherwise specified, rules="none".Other values of border imply frame="border" and, unless otherwise specified, rules="all".The value "border" in the start tag of the TABLE element should be interpreted as the value of the frame attribute. It implies rules="all" and some default (non-zero) value for the border attribute.For example, the following definitions are equivalent:<TABLE border="2"> <TABLE border="2" frame="border" rules="all"> as are the following:<TABLE border> <TABLE frame="border" rules="all"> Note. Theborderattribute also defines the border behavior for theOBJECTandIMGelements, but takes different values for those elements.11.3.2 Horizontal and vertical alignmentThe following attributes may be set for different table elements (see their definitions).<!-- horizontal alignment attributes for cell contents --> <!ENTITY % cellhalign  "align (left|center|right|justify|char) #IMPLIED  char %Character; #IMPLIED -- alignment char, e.g. char=':' --  charoff %Length; #IMPLIED -- offset for alignment char --"  > <!-- vertical alignment attributes for cell contents --> <!ENTITY % cellvalign  "valign (top|middle|bottom|baseline) #IMPLIED"  > Attribute definitionsalign=left|center|right|justify|char[CI]This attribute specifies the alignment of data and the justification of text in a cell. Possible values:left: Left-flush data/Left-justify text. This is the default value for table data.center: Center data/Center-justify text. This is the default value for table headers.right: Right-flush data/Right-justify text.justify: Double-justify text.char: Align text around a specific character. If a user agent doesn't support character alignment, behavior in the presence of this value is unspecified.valign=top|middle|bottom|baseline[CI]This attribute specifies the vertical position of data within a cell. Possible values:top: Cell data is flush with the top of the cell.middle: Cell data is centered vertically within the cell. This is the default value.bottom: Cell data is flush with the bottom of the cell.baseline: All cells in the same row as a cell whose valign attribute has this value should have their textual data positioned so that the first text line occurs on a baseline common to all cells in the row. This constraint does not apply to subsequent text lines in these cells.char= character [CN]This attribute specifies a single character within a text fragment to act as an axis for alignment. The default value for this attribute is the decimal point character for the current language as set by thelangattribute (e.g., the period (".") in English and the comma (",") in French). User agents are not required to support this attribute.charoff= length [CN]When present, this attribute specifies the offset to the first occurrence of the alignment character on each line. If a line doesn't include the alignment character, it should be horizontally shifted to end at the alignment position.Whencharoffis used to set the offset of an alignment character, the direction of offset is determined by the current text direction (set by thedirattribute). In left-to-right texts (the default), offset is from the left margin. In right-to-left texts, offset is from the right margin. User agents are not required to support this attribute.The table in this example aligns a row of currency values along a decimal point. We set the alignment character to "." explicitly.<TABLE border="1"> <COLGROUP> <COL><COL align="char" char="."> <THEAD> <TR><TH>Vegetable <TH>Cost per kilo <TBODY> <TR><TD>Lettuce <TD>$1 <TR><TD>Silver carrots <TD>$10.50 <TR><TD>Golden turnips <TD>$100.30 </TABLE> The formatted table may resemble the following:------------------------------ | Vegetable |Cost per kilo| |--------------|-------------| |Lettuce | $1 | |--------------|-------------| |Silver carrots| $10.50| |--------------|-------------| |Golden turnips| $100.30| ------------------------------ When the contents of a cell contain more than one instance of the alignment character specified bycharand the contents wrap, user agent behavior is undefined. Authors should therefore be attentive in their use ofchar.Note. Visual user agents typically renderTHelements vertically and horizontally centered within the cell and with a bold font weight.Inheritance of alignment specificationsThe alignment of cell contents can be specified on a cell by cell basis, or inherited from enclosing elements, such as the row, column or the table itself.The order of precedence (from highest to lowest) for the attributesalign,char, andcharoffis the following:An alignment attribute set on an element within a cell's data (e.g., P).An alignment attribute set on a cell (TH and TD).An alignment attribute set on a column grouping element (COL and COLGROUP). When a cell is part of a multi-column span, the alignment property is inherited from the cell definition at the beginning of the span.An alignment attribute set on a row or row grouping element (TR, THEAD, TFOOT, and TBODY). When a cell is part of a multi-row span, the alignment property is inherited from the cell definition at the beginning of the span.An alignment attribute set on the table (TABLE).The default alignment value.The order of precedence (from highest to lowest) for the attributevalign(as well as the other inherited attributeslang,dir, andstyle) is the following:An attribute set on an element within a cell's data (e.g., P).An attribute set on a cell (TH and TD).An attribute set on a row or row grouping element (TR, THEAD, TFOOT, and TBODY). When a cell is part of a multi-row span, the attribute value is inherited from the cell definition at the beginning of the span.An attribute set on a column grouping element (COL and COLGROUP). When a cell is part of a multi-column span, the attribute value is inherited from the cell definition at the beginning of the span.An attribute set on the table (TABLE).The default attribute value.Furthermore, when rendering cells, horizontal alignment is determined by columns in preference to rows, while for vertical alignment, rows are given preference over columns.The default alignment for cells depends on the user agent. However, user agents should substitute the default attribute for the current directionality (i.e., not just "left" in all cases).User agents that do not support the "justify" value of thealignattribute should use the value of the inherited directionality in its place.Note. Note that a cell may inherit an attribute not from its parent but from the first cell in a span. This is an exception to the general attribute inheritance rules.11.3.3 Cell marginsAttribute definitionscellspacing= length [CN]This attribute specifies how much space the user agent should leave between the left side of the table and the left-hand side of the leftmost column, the top of the table and the top side of the topmost row, and so on for the right and bottom of the table. The attribute also specifies the amount of space to leave between cells.cellpadding= length [CN]This attribute specifies the amount of space between the border of the cell and its contents. If the value of this attribute is a pixel length, all four margins should be this distance from the contents. If the value of the attribute is a percentage length, the top and bottom margins should be equally separated from the content based on a percentage of the available vertical space, and the left and right margins should be equally separated from the content based on a percentage of the available horizontal space.These two attributes control spacing between and within cells. The following illustration explains how they relate:In the following example, thecellspacingattribute specifies that cells should be separated from each other and from the table frame by twenty pixels. Thecellpaddingattribute specifies that the top margin of the cell and the bottom margin of the cell will each be separated from the cell's contents by 10% of the available vertical space (the total being 20%). Similarly, the left margin of the cell and the right margin of the cell will each be separated from the cell's contents by 10% of the available horizontal space (the total being 20%).<TABLE cellspacing="20" cellpadding="20%"> <TR> <TD>Data1 <TD>Data2 <TD>Data3 </TABLE> If a table or given column has a fixed width,cellspacingandcellpaddingmay demand more space than assigned. User agents may give these attributes precedence over thewidthattribute when a conflict occurs, but are not required to.11.4 Table rendering by non-visual user agents11.4.1 Associating header information with data cellsNon-visual user agents such as speech synthesizers and Braille-based devices may use the followingTDandTHelement attributes to render table cells more intuitively:For a given data cell, the headers attribute lists which cells provide pertinent header information. For this purpose, each header cell must be named using the id attribute. Note that it's not always possible to make a clean division of cells into headers or data. You should use the TD element for such cells together with the id or scope attributes as appropriate.For a given header cell, the scope attribute tells the user agent the data cells for which this header provides information. Authors may choose to use this attribute instead of headers according to which is more convenient; the two attributes fulfill the same function. The headers attribute is generally needed when headers are placed in irregular positions with respect to the data they apply to.The abbr attribute specifies an abbreviated header for header cells so that user agents may render header information more rapidly.In the following example, we assign header information to cells by setting theheadersattribute. Each cell in the same column refers to the same header cell (via theidattribute).<TABLE border="1"   summary="This table charts the number of cups  of coffee consumed by each senator, the type   of coffee (decaf or regular), and whether   taken with sugar."> <CAPTION>Cups of coffee consumed by each senator</CAPTION> <TR>  <TH id="t1">Name</TH>  <TH id="t2">Cups</TH>  <TH id="t3" abbr="Type">Type of Coffee</TH>  <TH id="t4">Sugar?</TH> <TR>  <TD headers="t1">T. Sexton</TD>  <TD headers="t2">10</TD>  <TD headers="t3">Espresso</TD>  <TD headers="t4">No</TD> <TR>  <TD headers="t1">J. Dinnen</TD>  <TD headers="t2">5</TD>  <TD headers="t3">Decaf</TD>  <TD headers="t4">Yes</TD> </TABLE> A speech synthesizer might render this table as follows:Caption: Cups of coffee consumed by each senator Summary: This table charts the number of cups  of coffee consumed by each senator, the type   of coffee (decaf or regular), and whether   taken with sugar. Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes Note how the header "Type of Coffee" is abbreviated to "Type" using theabbrattribute.Here is the same example substituting thescopeattribute for theheadersattribute. Note the value "col" for thescopeattribute, meaning "all cells in the current column":<TABLE border="1"   summary="This table charts the number of cups  of coffee consumed by each senator, the type   of coffee (decaf or regular), and whether   taken with sugar."> <CAPTION>Cups of coffee consumed by each senator</CAPTION> <TR>  <TH scope="col">Name</TH>  <TH scope="col">Cups</TH>  <TH scope="col" abbr="Type">Type of Coffee</TH>  <TH scope="col">Sugar?</TH> <TR>  <TD>T. Sexton</TD>  <TD>10</TD>  <TD>Espresso</TD>  <TD>No</TD> <TR>  <TD>J. Dinnen</TD>  <TD>5</TD>  <TD>Decaf</TD>  <TD>Yes</TD> </TABLE> Here's a somewhat more complex example illustrating other values for thescopeattribute:<TABLE border="1" cellpadding="5" cellspacing="2"  summary="History courses offered in the community of  Bath arranged by course name, tutor, summary,   code, and fee">  <TR>  <TH colspan="5" scope="colgroup">Community Courses -- Bath Autumn 1997</TH>  </TR>  <TR>  <TH scope="col" abbr="Name">Course Name</TH>  <TH scope="col" abbr="Tutor">Course Tutor</TH>  <TH scope="col">Summary</TH>  <TH scope="col">Code</TH>  <TH scope="col">Fee</TH>  </TR>  <TR>  <TD scope="row">After the Civil War</TD>  <TD>Dr. John Wroughton</TD>  <TD>  The course will examine the turbulent years in England  after 1646. <EM>6 weekly meetings starting Monday 13th  October.</EM>  </TD>  <TD>H27</TD>  <TD>&pound;32</TD>  </TR>  <TR>  <TD scope="row">An Introduction to Anglo-Saxon England</TD>  <TD>Mark Cottle</TD>  <TD>  One day course introducing the early medieval  period reconstruction the Anglo-Saxons and  their society. <EM>Saturday 18th October.</EM>  </TD>  <TD>H28</TD>  <TD>&pound;18</TD>  </TR>  <TR>  <TD scope="row">The Glory that was Greece</TD>  <TD>Valerie Lorenz</TD>  <TD>  Birthplace of democracy, philosophy, heartland of theater, home of  argument. The Romans may have done it but the Greeks did it  first. <EM>Saturday day school 25th October 1997</EM>  </TD>  <TD>H30</TD>  <TD>&pound;18</TD>  </TR> </TABLE> A graphical user agent might render this as:Note the use of thescopeattribute with the "row" value. Although the first cell in each row contains data, not header information, thescopeattribute makes the data cell behave like a row header cell. This allows speech synthesizers to provide the relevant course name upon request or to state it immediately before each cell's content.11.4.2 Categorizing cellsUsers browsing a table with a speech-based user agent may wish to hear an explanation of a cell's contents in addition to the contents themselves. One way the user might provide an explanation is by speaking associated header information before speaking the data cell's contents (see the section on associating header information with data cells).Users may also want information about more than one cell, in which case header information provided at the cell level (byheaders,scope, andabbr) may not provide adequate context. Consider the following table, which classifies expenses for meals, hotels, and transport in two locations (San Jose and Seattle) over several days:Users might want to extract information from the table in the form of queries:"What did I spend for all my meals?""What did I spend for meals on 25 August?""What did I spend for all expenses in San Jose?"Each query involves a computation by the user agent that may involve zero or more cells. In order to determine, for example, the costs of meals on 25 August, the user agent must know which table cells refer to "Meals" (all of them) and which refer to "Dates" (specifically, 25 August), and find the intersection of the two sets.To accommodate this type of query, the HTML 4 table model allows authors to place cell headers and data into categories. For example, for the travel expense table, an author could group the header cells "San Jose" and "Seattle" into the category "Location", the headers "Meals", "Hotels", and "Transport" in the category "Expenses", and the four days into the category "Date". The previous three questions would then have the following meanings:"What did I spend for all my meals?" means "What are all the data cells in the "Expenses=Meals" category?"What did I spend for meals on 25 August?" means "What are all the data cells in the "Expenses=Meals" and "Date=Aug-25-1997" categories?"What did I spend for all expenses in San Jose?" means "What are all the data cells in the "Expenses=Meals, Hotels, Transport" and "Location=San Jose" categories?Authors categorize a header or data cell by setting theaxisattribute for the cell. For instance, in the travel expense table, the cell containing the information "San Jose" could be placed in the "Location" category as follows: <TH id="a6" axis="location">San Jose</TH> Any cell containing information related to "San Jose" should refer to this header cell via either theheadersor thescopeattribute. Thus, meal expenses for 25-Aug-1997 should be marked up to refer toidattribute (whose value here is "a6") of the "San Jose" header cell:   <TD headers="a6">37.74</TD> Eachheadersattribute provides a list ofidreferences. Authors may thus categorize a given cell in any number of ways (or, along any number of "headers", hence the name).Below we mark up the travel expense table with category information:<TABLE border="1"  summary="This table summarizes travel expenses  incurred during August trips to  San Jose and Seattle"> <CAPTION>  Travel Expense Report </CAPTION> <TR>  <TH></TH>  <TH id="a2" axis="expenses">Meals</TH>  <TH id="a3" axis="expenses">Hotels</TH>  <TH id="a4" axis="expenses">Transport</TH>  <TD>subtotals</TD> </TR> <TR>  <TH id="a6" axis="location">San Jose</TH>  <TH></TH>  <TH></TH>  <TH></TH>  <TD></TD> </TR> <TR>  <TD id="a7" axis="date">25-Aug-97</TD>  <TD headers="a6 a7 a2">37.74</TD>  <TD headers="a6 a7 a3">112.00</TD>  <TD headers="a6 a7 a4">45.00</TD>  <TD></TD> </TR> <TR>  <TD id="a8" axis="date">26-Aug-97</TD>  <TD headers="a6 a8 a2">27.28</TD>  <TD headers="a6 a8 a3">112.00</TD>  <TD headers="a6 a8 a4">45.00</TD>  <TD></TD> </TR> <TR>  <TD>subtotals</TD>  <TD>65.02</TD>  <TD>224.00</TD>  <TD>90.00</TD>  <TD>379.02</TD> </TR> <TR>  <TH id="a10" axis="location">Seattle</TH>  <TH></TH>  <TH></TH>  <TH></TH>  <TD></TD> </TR> <TR>  <TD id="a11" axis="date">27-Aug-97</TD>  <TD headers="a10 a11 a2">96.25</TD>  <TD headers="a10 a11 a3">109.00</TD>  <TD headers="a10 a11 a4">36.00</TD>  <TD></TD> </TR> <TR>  <TD id="a12" axis="date">28-Aug-97</TD>  <TD headers="a10 a12 a2">35.00</TD>  <TD headers="a10 a12 a3">109.00</TD>  <TD headers="a10 a12 a4">36.00</TD>  <TD></TD> </TR> <TR>  <TD>subtotals</TD>  <TD>131.25</TD>  <TD>218.00</TD>  <TD>72.00</TD>  <TD>421.25</TD> </TR> <TR>  <TH>Totals</TH>  <TD>196.27</TD>  <TD>442.00</TD>  <TD>162.00</TD>  <TD>800.27</TD> </TR> </TABLE> Note that marking up the table this way also allows user agents to avoid confusing the user with unwanted information. For instance, if a speech synthesizer were to speak all of the figures in the "Meals" column of this table in response to the query "What were all my meal expenses?", a user would not be able to distinguish a day's expenses from subtotals or totals. By carefully categorizing cell data, authors allow user agents to make important semantic distinctions when rendering.Of course, there is no limit to how authors may categorize information in a table. In the travel expense table, for example, we could add the additional categories "subtotals" and "totals".This specification does not require user agents to handle information provided by theaxisattribute, nor does it make any recommendations about how user agents may presentaxisinformation to users or how users may query the user agent about this information.However, user agents, particularly speech synthesizers, may want to factor out information common to several cells that are the result of a query. For instance, if the user asks "What did I spend for meals in San Jose?", the user agent would first determine the cells in question (25-Aug-1997: 37.74, 26-Aug-1997:27.28), then render this information. A user agent speaking this information might read it: Location: San Jose. Date: 25-Aug-1997. Expenses, Meals: 37.74  Location: San Jose. Date: 26-Aug-1997. Expenses, Meals: 27.28 or, more compactly: San Jose, 25-Aug-1997, Meals: 37.74  San Jose, 26-Aug-1997, Meals: 27.28 An even more economical rendering would factor the common information and reorder it: San Jose, Meals, 25-Aug-1997: 37.74  26-Aug-1997: 27.28 User agents that support this type of rendering should allow user agents a means to customize rendering (e.g., through style sheets).11.4.3 Algorithm to find heading informationIn the absence of header information from either thescopeorheadersattribute, user agents may construct header information according to the following algorithm. The goal of the algorithm is to find an ordered list of headers. (In the following description of the algorithm the table directionality is assumed to be left-to-right.)First, search left from the cell's position to find row header cells. Then search upwards to find column header cells. The search in a given direction stops when the edge of the table is reached or when a data cell is found after a header cell.Row headers are inserted into the list in the order they appear in the table. For left-to-right tables, headers are inserted from left to right.Column headers are inserted after row headers, in the order they appear in the table, from top to bottom.If a header cell has the headers attribute set, then the headers referenced by this attribute are inserted into the list and the search stops for the current direction.TD cells that set the axis attribute are also treated as header cells.11.5 Sample tableThis sample illustrates grouped rows and columns. The example is adapted from "Developing International Software", by Nadine Kano.In "ascii art", the following table:<TABLE border="2" frame="hsides" rules="groups"  summary="Code page support in different versions  of MS Windows."> <CAPTION>CODE-PAGE SUPPORT IN MICROSOFT WINDOWS</CAPTION> <COLGROUP align="center"> <COLGROUP align="left"> <COLGROUP align="center" span="2"> <COLGROUP align="center" span="3"> <THEAD valign="top"> <TR> <TH>Code-Page<BR>ID <TH>Name <TH>ACP <TH>OEMCP <TH>Windows<BR>NT 3.1 <TH>Windows<BR>NT 3.51 <TH>Windows<BR>95 <TBODY> <TR><TD>1200<TD>Unicode (BMP of ISO/IEC-10646)<TD><TD><TD>X<TD>X<TD>* <TR><TD>1250<TD>Windows 3.1 Eastern European<TD>X<TD><TD>X<TD>X<TD>X <TR><TD>1251<TD>Windows 3.1 Cyrillic<TD>X<TD><TD>X<TD>X<TD>X <TR><TD>1252<TD>Windows 3.1 US (ANSI)<TD>X<TD><TD>X<TD>X<TD>X <TR><TD>1253<TD>Windows 3.1 Greek<TD>X<TD><TD>X<TD>X<TD>X <TR><TD>1254<TD>Windows 3.1 Turkish<TD>X<TD><TD>X<TD>X<TD>X <TR><TD>1255<TD>Hebrew<TD>X<TD><TD><TD><TD>X <TR><TD>1256<TD>Arabic<TD>X<TD><TD><TD><TD>X <TR><TD>1257<TD>Baltic<TD>X<TD><TD><TD><TD>X <TR><TD>1361<TD>Korean (Johab)<TD>X<TD><TD><TD>**<TD>X <TBODY> <TR><TD>437<TD>MS-DOS United States<TD><TD>X<TD>X<TD>X<TD>X <TR><TD>708<TD>Arabic (ASMO 708)<TD><TD>X<TD><TD><TD>X <TR><TD>709<TD>Arabic (ASMO 449+, BCON V4)<TD><TD>X<TD><TD><TD>X <TR><TD>710<TD>Arabic (Transparent Arabic)<TD><TD>X<TD><TD><TD>X <TR><TD>720<TD>Arabic (Transparent ASMO)<TD><TD>X<TD><TD><TD>X </TABLE> would be rendered something like this: CODE-PAGE SUPPORT IN MICROSOFT WINDOWS =============================================================================== Code-Page | Name | ACP OEMCP | Windows Windows Windows  ID | | | NT 3.1 NT 3.51 95 -------------------------------------------------------------------------------  1200 | Unicode (BMP of ISO 10646) | | X X *  1250 | Windows 3.1 Eastern European | X | X X X  1251 | Windows 3.1 Cyrillic | X | X X X  1252 | Windows 3.1 US (ANSI) | X | X X X  1253 | Windows 3.1 Greek | X | X X X  1254 | Windows 3.1 Turkish | X | X X X  1255 | Hebrew | X | X  1256 | Arabic | X | X  1257 | Baltic | X | X  1361 | Korean (Johab) | X | ** X -------------------------------------------------------------------------------  437 | MS-DOS United States | X | X X X  708 | Arabic (ASMO 708) | X | X  709 | Arabic (ASMO 449+, BCON V4) | X | X  710 | Arabic (Transparent Arabic) | X | X  720 | Arabic (Transparent ASMO) | X | X =============================================================================== A graphical user agent might render this as:

Fact tables contain the detailed ‘transactions’ that occur in your ecosystem. Examples can include each cash payment you receive as a row in the table, each sale made, or every login to your system. Traditionally it has been best practice to store these transactions in a ‘normalised’ form which means you only store the identifier/codes for the data fields that aren't amounts or dates.For instance if your fact data set was normalised corporate sales data it would probably contain fields like:Date of Sale: 2020-03-25 09:07:43Invoice Number: 12557Customer ID: 5332Product ID: 27Currency Code: USDAmount: 120.00This is generally perceived as the most efficient way to store the data as you're not clogging up the table with descriptions of the currency or names (that could change) of the product and customer.Dimensions, to (over) simplify things, are the ‘lookup’ tables that contain all the missing descriptions and additional information about the entities you have the codes for. In the data above you would use a ‘product dimension’ to add new fields to the data set like:Product ID: 27 (this field exists in both dimensions and facts, allowing you to link the data sets together)Product Name: Red Rider BB GunProduct Start Date: 1950-12–25Product Type: 2 (dimensions can link to other dimensions, in this example a Product Type table that contains the description and additional information about those types).By combining the facts and dimensions and merging the data sets together, you create a ‘denormalised’ view of the data which means all the IDs, codes, and descriptions are all exposed in the same view/table. Analysts and end users find this view of the data easiest to work with as it's a ‘one stop shop’ for everything but it's also larger (aka slower and more expensive) to manage and update.There's lots of other nuances related to hierarchies, master/reference data, and effective dating as well as the relationship of fact/dim concepts to building cubes vs views vs new tables, but this is the simplified definitions.

“Document type definition - Wikipedia”“A document type definition (DTD) is a set of markup declarations that define a document type for an SGML-family markup language (GML, SGML, XML, HTML).A DTD defines the valid building blocks of an XML document. It defines the document structure with a list of validated elements and attributes. A DTD can be declared inline inside an XML document, or as an external reference. XML uses a subset of SGML DTD.As of 2009, newer XML namespace-aware schema languages (such as W3C XML Schema and ISO RELAX NG) have largely superseded DTDs. A namespace-aware version of DTDs is being developed as Part 9 of ISO DSDL. DTDs persist in applications that need special publishing characters, such as the XML and HTML Character Entity References, which derive from larger sets defined as part of the ISO SGML standard effort.Associating DTDs with documentsA DTD is associated with an XML or SGML document by means of a document type declaration (DOCTYPE). The DOCTYPE appears in the syntactic fragment doctypedecl near the start of an XML document. The declaration establishes that the document is an instance of the type defined by the referenced DTD.DOCTYPEs make two sorts of declaration:an optional external subsetan optional internal subset.The declarations in the internal subset form part of the DOCTYPE in the document itself. The declarations in the external subset are located in a separate text file. The external subset may be referenced via a public identifier and/or a system identifier. Programs for reading documents may not be required to read the external subset.Any valid SGML or XML document that references an external subset in its DTD, or whose body contains references to parsed external entities declared in its DTD (including those declared within its internal subset), may only be partially parsed but cannot be fully validated by validating SGML or XML parsers in their standalone mode (this means that these validating parsers don't attempt to retrieve these external entities, and their replacement text is not accessible).However, such documents are still fully parsable in the non-standalone mode of validating parsers, which signals an error if it can't locate these external entities with their specified public identifier (FPI) or system identifier (a URI), or are inaccessible. (Notations declared in the DTD are also referencing external entities, but these unparsed entities are not needed for the validation of documents in the standalone mode of these parsers: the validation of all external entities referenced by notations is left to the application using the SGML or XML parser). Non-validating parsers may eventually attempt to locate these external entities in the non-standalone mode (by partially interpreting the DTD only to resolve their declared parsable entities), but do not validate the content model of these documents.ExamplesThe following example of a DOCTYPE contains both public and system identifiers:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> All HTML 4.01 documents conform to one of three SGML DTDs. The public identifiers of these DTDs are constant and are as follows:-//W3C//DTD HTML 4.01//EN-//W3C//DTD HTML 4.01 Transitional//EN-//W3C//DTD HTML 4.01 Frameset//ENThe system identifiers of these DTDs, if present in the DOCTYPE, are URI references. A system identifier usually points to a specific set of declarations in a resolvable location. SGML allows mapping public identifiers to system identifiers in catalogues that are optionally available to the URI resolvers used by document parsing software.This DOCTYPE can only appear after the optional XML declaration, and before the document body, if the document syntax conforms to XML. This includes XHTML documents:<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!-- the XHTML document body starts here--> <html xmlns="http://www.w3.org/1999/xhtml">  ... </html> An additional internal subset can also be provided after the external subset:<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [  <!-- an internal subset can be embedded here --> ]> <!-- the XHTML document body starts here--> <html xmlns="http://www.w3.org/1999/xhtml">  ... </html> Alternatively, only the internal subset may be provided:<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html [  <!-- an internal subset can be embedded here --> ]> <!-- the XHTML document body starts here--> <html xmlns="http://www.w3.org/1999/xhtml">  ... </html> Finally, the document type definition may include no subset at all; in that case, it just specifies that the document has a single top-level element (this is an implicit requirement for all valid XML and HTML documents, but not for document fragments or for all SGML documents, whose top-level elements may be different from the implied root element), and it indicates the type name of the root element:<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html> <!-- the XHTML document body starts here--> <html xmlns="http://www.w3.org/1999/xhtml">  ... </html> Markup declarationsDTDs describe the structure of a class of documents via element and attribute-list declarations. Element declarations name the allowable set of elements within the document, and specify whether and how declared elements and runs of character data may be contained within each element. Attribute-list declarations name the allowable set of attributes for each declared element, including the type of each attribute value, if not an explicit set of valid values.DTD markup declarations declare which element types, attribute lists, entities, and notations are allowed in the structure of the corresponding class of XML documents.Element type declarationsAn element type declaration defines an element and its possible content. A valid XML document contains only elements that are defined in the DTD.Various keywords and characters specify an element's content:EMPTY for specifying that the defined element allows no content, i.e., it cannot have any children elements, not even text elements (if there are whitespaces, they are ignored);ANY for specifying that the defined element allows any content, without restriction, i.e., that it may have any number (including none) and type of children elements (including text elements);or an expression, specifying the only elements allowed as direct children in the content of the defined element; this content can be either : a mixed content, which means that the content may include at least one text element and zero or more named elements, but their order and number of occurrences cannot be restricted; this can be:( #PCDATA ): historically meaning parsed character data, this means that only one text element is allowed in the content (no quantifier is allowed);( #PCDATA | ''element name'' | ... )*: a limited choice (in an exclusive list between parentheses and separated by "|" pipe characters and terminated by the required "*" quantifier) of two or more child elements (including only text elements or the specified named elements) may be used in any order and number of occurrences in the http://content.an element content, which means that there must be no text elements in the children elements of the content (all whitespaces encoded between child elements are then ignored, just like comments). Such element content is specified as content particle in a variant of Backus–Naur form without terminal symbols and element names as non-terminal symbols. Element content consists of : a content particle can be either the name of an element declared in the DTD, or a sequence list or choice list. It may be followed by an optional quantifier. a sequence list means an ordered list (specified between parentheses and separated by a "," comma character) of one or more content particles: all the content particles must appear successively as direct children in the content of the defined element, at the specified position and relative order; a choice list means a mutually exclusive list (specified between parentheses and separated by a "|" pipe character) of two or more content particles: only one of these content particles may appear in the content of the defined element at the same position. A quantifier is a single character that immediately follows the specified item it applies to, to restrict the number of successive occurrences of these items at the specified position in the content of the element; it may be either:+ for specifying that there must be one or more occurrences of the item — the effective content of each occurrence may be different;* for specifying that any number (zero or more) of occurrences is allowed — the item is optional and the effective content of each occurrence may be different;? for specifying that there must not be more than one occurrence — the item is optional; If there is no quantifier, the specified item must occur exactly one time at the specified position in the content of the element.For example:<!ELEMENT html (head, body)> <!ELEMENT p (#PCDATA | p | ul | dl | table | h1|h2|h3)*> Element type declarations are ignored by non-validating SGML and XML parsers (in which cases, any elements are accepted in any order, and in any number of occurrences in the parsed document), but these declarations are still checked for form and validity.Attribute list declarationsAn attribute list specifies for a given element type the list of all possible attribute associated with that type. For each possible attribute, it contains:the declared name of the attribute,its data type (or an enumeration of its possible values),and its default value.[4]For example:<!ATTLIST img  src CDATA #REQUIRED  id ID #IMPLIED  sort CDATA #FIXED "true"  print (yes | no) "yes" > Here are some attribute types supported by both SGML and XML:CDATAthis type means characters data and indicates that the effective value of the attribute can be any textual value, unless the attribute is specified as fixed (the comments in the DTD may further document values that are effectively accepted, but the DTD syntax does not allow such precise specification);ID the effective value of the attribute must be a valid identifier, and it is used to define and anchor to the current element the target of references using this defined identifier (including as document fragment identifiers that may be specified at end of an URI after a "#" sign); it is an error if distinct elements in the same document are defining the same identifier; the uniqueness constraint also implies that the identifier itself carries no other semantics and that identifiers must be treated as opaque in applications; XML also predefines the standard pseudo-attribute "xml:id" with this type, without needing any declaration in the DTD, so the uniqueness constraint also applies to these defined identifiers when they are specified anywhere in a XML document.IDREF or IDREFSthe effective value of the attribute can only be a valid identifier (or a space-separated list of such identifiers) and must be referencing the unique element defined in the document with an attribute declared with the type ID in the DTD (or the unique element defined in an XML document with a pseudo-attribute "xml:id") and whose effective value is the same identifier;NMTOKEN or NMTOKENSthe effective value of the attribute can only be a valid name token (or a spaced-separated list of such name tokens), but it is not restricted to a unique identifier within the document; this name may carry supplementary and application-dependent semantics and may require additional naming constraints, but this is out of scope of the DTD;ENTITY or ENTITIESthe effective value of the attribute can only be the name of an unparsed external entity (or a space-separated list of such names), which must also be declared in the document type declaration; this type is not supported in HTML parsers, but is valid in SGML and XML 1.0 or 1.1 (including XHTML and SVG);(''value1''|...)the effective value of the attribute can only be one of the enumerated list (specified between parentheses and separated by a "|" pipe character) of textual values, where each value in the enumeration is possibly specified between 'single' or "double" quotation marks if it's not a simple name token;NOTATION (''notation1''|...)the effective value of the attribute can only be any one of the enumerated list (specified between parentheses and separated by a "|" pipe character) of notation names, where each notation name in the enumeration must also be declared in the document type declaration; this type is not supported in HTML parsers, but is valid in SGML and XML 1.0 or 1.1 (including XHTML and SVG).A default value can define whether an attribute must occur (#REQUIRED) or not (#IMPLIED), or whether it has a fixed value (#FIXED), or which value should be used as a default value ("…") in case the given attribute is left out in an XML tag.Attribute list declarations are ignored by non-validating SGML and XML parsers (in which cases any attribute is accepted within all elements of the parsed document), but these declarations are still checked for well-formedness and validity.Entity declarationsAn entity is similar to a macro. The entity declaration assigns it a value that is retained throughout the document. A common use is to have a name more recognizable than a numeric character reference for an unfamiliar character. Entities help to improve legibility of an XML text. In general, there are two types: internal and external.Internal (parsed) entities are associating a name with any arbitrary textual content defined in their declaration (which may be in the internal subset or in the external subset of the DTD declared in the document). When a named entity reference is then encountered in the rest of the document (including in the rest of the DTD), and if this entity name has effectively been defined as a parsed entity, the reference itself is replaced immediately by the textual content defined in the parsed entity, and the parsing continues within this replacement text. Predefined named character entities are similar to internal entities: 5 of them however are treated specially in all SGML, HTML and XML parsers. These entities are a bit different from normal parsed entities, because when a named character entity reference is encountered in the document, the reference is also replaced immediately by the character content defined in the entity, but the parsing continues after the replacement text, which is immediately inserted literally in the currently parsed token (if such character is permitted in the textual value of that token). This allows some characters that are needed for the core syntax of HTML or XML themselves to be escaped from their special syntactic role (notably "&" which is reserved for beginning entity references, "<" or ">" which delimit the markup tags, and "double" or 'single' quotation marks, which delimit the values of attributes and entity definitions). Predefined character entities also include numeric character references that are handled the same way and can also be used to escape the characters they represent, or to bypass limitations in the character repertoire supported by the document Encoding.in domain name is for sale. Inquire now. basic profiles for SGML or in HTML documents, the declaration of internal entities is not possible (because external DTD subsets are not retrieved, and internal DTD subsets are not supported in these basic profiles).Instead, HTML standards predefine a large set of several hundred named character entities, which can still be handled as standard parsed entities defined in the DTD used by the parser.External entities refer to external storage objects. They are just declared by a unique name in the document, and defined with a public identifier (an FPI) and/or a system identifier (interpreted as an URI) specifying where the source of their content. They exist in fact in two variants : parsed external entities (most often defined with a SYSTEM identifier indicating the URI of their content) that are not associated in their definition to a named annotation, in which case validating XML or SGML parsers retrieve their contents and parse them as if they were declared as internal entities (the external entity containing their effective replacement text); unparsed external entities that are defined and associated with an annotation name, in which case they are treated as opaque references and signalled as such to the application using the SGML or XML parser: their interpretation, retrieval and parsing is left to the application, according to the types of annotations it supports (see the next section about annotations and for examples of unparsed external entities).External entities are not supported in basic profiles for SGML or in HTML documents, but are valid in full implementations of SGML and in XML 1.0 or 1.1 (including XHTML and SVG, even if they are not strictly needed in those document types).An example of internal entity declarations (here in an internal DTD subset of an SGML document) is:<!DOCTYPE sgml [  <!ELEMENT sgml ANY>  <!ENTITY % std "standard SGML">  <!ENTITY % signature " &#x2014; &author;.">  <!ENTITY % question "Why couldn&#x2019;t I publish my books directly in %std;?">  <!ENTITY % author "William Shakespeare"> ]>  <sgml>&question;&signature;</sgml> Internal entities may be defined in any order, as long as they are not referenced and parsed in the DTD or in the body of the document, in their order of parsing: it is valid to include a reference to a still undefined entity within the content of a parsed entity, but it is invalid to include anywhere else any named entity reference before this entity has been fully defined, including all other internal entities referenced in its defined content (this also prevents circular or recursive definitions of internal entities). This document is parsed as if it was:<!DOCTYPE sgml [  <!ELEMENT sgml ANY>  <!ENTITY % std "standard SGML">  <!ENTITY % signature " — &author;.">  <!ENTITY % question "Why couldn’t I publish my books directly in standard SGML?">  <!ENTITY % author "William Shakespeare"> ]>  <sgml>Why couldn’t I publish my books directly in standard SGML? — William Shakespeare.</sgml> Reference to the "author" internal entity is not substituted in the replacement text of the "signature" internal entity. Instead, it is replaced only when the "signature" entity reference is parsed within the content of the "sgml" element, but only by validating parsers (non-validating parsers do not substitute entity references occurring within contents of element or within attribute values, in the body of the document.This is possible because the replacement text specified in the internal entity definitions permits a distinction between parameter entity references (that are introduced by the "%" character and whose replacement applies to the parsed DTD contents) and general entity references (that are introduced by the "&" character and whose replacement is delayed until they are effectively parsed and validated). The "%" character for introducing parameter entity references in the DTD loses its special role outside the DTD and it becomes a literal character.However, the references to predefined numeric character entities are substituted wherever they occur, without needing a validating parser (they are only introduced by the "&" character).Notation declarationsNotations are used in SGML or XML. They provide a complete reference to unparsed external entities whose interpretation is left to the application (which interprets them directly or retrieves the external entity themselves), by assigning them a simple name, which is usable in the body of the document. For example, notations may be used to reference non-XML data in an XML 1.1 document. For example, to annotate SVG images to associate them with a specific renderer:<!NOTATION type-image-svg SYSTEM "image/svg"> This declares the MIME type of external images with this type, and associates it with a notation name "type-image-svg". However, notation names usually follow a naming convention that is specific to the application generating or using the notation: notations are interpreted as additional meta-data whose effective content is an external entity and either a PUBLIC FPI, registered in the catalogues used by XML or SGML parsers, or a SYSTEM URI, whose interpretation is application dependent (here a MIME type, interpreted as a relative URI, but it could be an absolute URI to a specific renderer, or a URN indicating an OS-specific object identifier such as a UUID).The declared notation name must be unique within all the document type declaration, i.e. in the external subset as well as the internal subset, at least for conformance with XML. Notations can be associated to unparsed external entities included in the body of the SGML or XML document. The PUBLIC or SYSTEM parameter of these external entities specifies the FPI and/or the URI where the unparsed data of the external entity is located, and the additional NDATA parameter of these defined entities specifies the additional notation (i.e., effectively the MIME type here). For example:<!DOCTYPE sgml [  <!ELEMENT sgml (img)*>   <!ELEMENT img EMPTY>  <!ATTLIST img  data ENTITY #IMPLIED>   <!ENTITY example1SVG SYSTEM "example1.svg" NDATA example1SVG-rdf>  <!NOTATION example1SVG-rdf SYSTEM "example1.svg.rdf"> ]>  <sgml>  <img data="example1SVG" /> </sgml> Within the body of the SGML document, these referenced external entities (whose name is specified between "&" and ";") are not replaced like usual named entities (defined with a CDATA value), but are left as distinct unparsed tokens that may be used either as the value of an element attribute (like above) or within the element contents, provided that either the DTD allows such external entities in the declared content type of elements or in the declared type of attributes (here the ENTITY type for the data attribute), or the SGML parser is not validating the content.Notations may also be associated directly to elements as additional meta-data, without associating them to another external entity, by giving their names as possible values of some additional attributes (also declared in the DTD within the <!ATTLIST ...> declaration of the element). For example:<!DOCTYPE sgml [  <!ELEMENT sgml (img)*>  <!--  the optional "type" attribute value can only be set to this notation.  -->  <!ATTLIST sgml  type NOTATION (  type-vendor-specific ) #IMPLIED>   <!ELEMENT img ANY> <!-- optional content can be only parsable SGML or XML data -->  <!--  The optional "title" attribute value must be parsable as text.  The optional "data" attribute value is set to an unparsed external entity.  The optional "type" attribute value can only be one of the two notations.  -->  <!ATTLIST img  title CDATA #IMPLIED  data ENTITY #IMPLIED  type NOTATION (  type-image-svg |  type-image-gif ) #IMPLIED>   <!--  Notations are referencing external entities and may be set in the "type" attributes above,  or must be referenced by any defined external entities that cannot be parsed.  -->  <!NOTATION type-image-svg PUBLIC "-//W3C//DTD SVG 1.1//EN"  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">  <!NOTATION type-image-gif PUBLIC "image/gif">  <!NOTATION type-vendor-specific PUBLIC "application/VND.specific+sgml">   <!ENTITY example1SVGTitle "Title of example1.svg"> <!-- parsed internal entity -->  <!ENTITY example1SVG SYSTEM "example1.svg"> <!-- parsed external entity -->  <!ENTITY example1GIFTitle "Title of example1.gif"> <!-- parsed internal entity -->  <!ENTITY example1GIF SYSTEM "example1.gif" NDATA type-image-gif> <!-- unparsed external entity --> ]>  <sgml type="type-vendor-specific">  <!-- an SVG image is parsable as valid SGML or XML text -->  <img title="&example1SVGTitle;" type="type-image-svg">&example1SVG;</img>   <!-- it can also be referenced as an unparsed external entity -->  <img title="&example1SVGTitle;" data="example1SVG" />   <!-- a GIF image is not parsable and can only be referenced as an external entity -->  <img title="&example1GIFTitle;" data="example1GIF" /> </sgml> The example above shows a notation named "type-image-svg" that references the standard public FPI and the system identifier (the standard URI) of an SVG 1.1 document, instead of specifying just a system identifier as in the first example (which was a relative URI interpreted locally as a MIME type). This annotation is referenced directly within the unparsed "type" attribute of the "img" element, but its content is not retrieved. It also declares another notation for a vendor-specific application, to annotate the "sgml" root element in the document. In both cases, the declared notation named is used directly in a declared "type" attribute, whose content is specified in the DTD with the "NOTATION" attribute type (this "type" attribute is declared for the "sgml" element, as well as for the "img" element).However, the "title" attribute of the "img" element specifies the internal entity "example1SVGTitle" whose declaration that does not define an annotation, so it is parsed by validating parsers and the entity replacement text is "Title of example1.svg".The content of the "img" element references another external entity "example1SVG" whose declaration also does not define an notation, so it is also parsed by validating parsers and the entity replacement text is located by its defined SYSTEM identifier "example1.svg" (also interpreted as a relative URI). The effective content for the "img" element be the content of this second external resource. The difference with the GIF image, is that the SVG image is parsed within the SGML document, according to the declarations in the DTD, where the GIF image is just referenced as an opaque external object (which is not parsable with SGML) via its "data" attribute (whose value type is an opaque ENTITY).Only one notation name may be specified in the value of ENTITY attributes (there's no support in SGML, XML 1.0 or XML 1.1 for multiple notation names in the same declared external ENTITY, so separate attributes are needed). However multiple external entities may be referenced (in a space-separated list of names) in attributes declared with type ENTITIES, and where each named external entity is also declared with its own notation).Notations are also completely opaque for XML and SGML parsers, so they are not differentiated by the type of the external entity that they may reference (for these parsers they just have a unique name associated to a public identifier (an FPI) and/or a system identifier (a URI)).Some applications (but not XML or SGML parsers themselves) also allow referencing notations indirectly by naming them in the "URN:''name''" value of a standard CDATA attribute, everywhere a URI can be specified. However this behaviour is application-specific, and requires that the application maintains a catalog of known URNs to resolve them into the notations that have been parsed in a standard SGML or XML parser. This use allows notations to be defined only in a DTD stored as an external entity and referenced only as the external subset of documents, and allows these documents to remain compatible with validating XML or SGML parsers that have no direct support for notations.Notations are not used in HTML, or in basic profiles for XHTML and SVG, because:All external entities used by these standard document types are referenced by simple attributes, declared with the CDATA type in their standard DTD (such as the "href" attribute of an anchor "a" element, or the "src" attribute of an image "img" element, whose values are interpreted as a URI, without needing any catalogue of public identifiers, i.e., known FPI)All external entities for additional meta-data are referenced by either : Additional attributes (such as type, which indicates the MIME type of the external entity, or the charset attribute, which indicates its encoding)Additional elements (such as link or meta in HTML and XHTML) within their own attributes Standard pseudo-attributes in XML and XHTML (such as xml:lang, or xmlns and xmlns:* for namespace declarations).Even in validating SGML or XML 1.0 or XML 1.1 parsers, the external entities referenced by an FPI and/or URI in declared notations are not retrieved automatically by the parsers themselves. Instead, these parsers just provide to the application the parsed FPI and/or URI associated to the notations found in the parsed SGML or XML document, and with a facility for a dictionary containing all notation names declared in the DTD; these validating parsers also check the uniqueness of notation name declarations, and report a validation error if some notation names are used anywhere in the DTD or in the document body but not declared:If the application can't use any notation (or if their FPI and/or URI are unknown or not supported in their local catalogue), these notations may be either ignored silently by the application or the application could signal an error.Otherwise, the applications decide themselves how to interpret them, then if the external entities must be retrieved and then parsed separately.Applications may then signal an error, if such interpretation, retrieval or separate parsing fails.Unrecognized notations that may cause an application to signal an error should not block interpretation of the validated document using them.XML DTDs and schema validationThe XML DTD syntax is one of several XML schema languages. However, many of the schema languages do not fully replace the XML DTD. Notably, the XML DTD allows defining entities and notations that have no direct equivalents in DTD-less XML (because internal entities and parsable external entities are not part of XML schema languages, and because other unparsed external entities and notations have no simple equivalent mappings in most XML schema languages).Most XML schema languages are only replacements for element declarations and attribute list declarations, in such a way that it becomes possible to parse XML documents with non-validating XML parsers (if the only purpose of the external DTD subset was to define the schema). In addition, documents for these XML schema languages must be parsed separately, so validating the schema of XML documents in pure standalone mode is not really possible with these languages: the document type declaration remains necessary for at least identifying (with a XML Catalogue) the schema used in the parsed XML document and that is validated in another language.A common misconception holds that a non-validating XML parser does not have to read document type declarations, when in fact, the document type declarations must still be scanned for correct syntax as well as validity of declarations, and the parser must still parse all entity declarations in the internal subset, and substitute the replacement texts of internal entities occurring anywhere in the document type declaration or in the document body.A non-validating parser may, however, elect not to read parsable external entities (including the external subset), and does not have to honour the content model restrictions defined in element declarations and in attribute list declarations.If the XML document depends on parsable external entities (including the specified external subset, or parsable external entities declared in the internal subset), it should assert standalone="no" in its XML declaration. The validating DTD may be identified by using XML Catalogues to retrieve its specified external subset.In the example below, the XML document is declared with standalone="no" because it has an external subset in its document type declaration:<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE people_list SYSTEM "example.dtd"> <people_list /> If the XML document type declaration includes any SYSTEM identifier for the external subset, it can't be safely processed as standalone: the URI should be retrieved, otherwise there may be unknown named character entities whose definition may be needed to correctly parse the effective XML syntax in the internal subset or in the document body (the XML syntax parsing is normally performed after the substitution of all named entities, excluding the five entities that are predefined in XML and that are implicitly substituted after parsing the XML document into lexical tokens). If it just includes any PUBLIC identifier, it may be processed as standalone, if the XML processor knows this PUBLIC identifier in its local catalogue from where it can retrieve an associated DTD entity.XML DTD schema exampleAn example of a very simple external XML DTD to describe the schema of a list of persons might consist of:<!ELEMENT people_list (person)*> <!ELEMENT person (name, birthdate?, gender?, socialsecuritynumber?)> <!ELEMENT name (#PCDATA)> <!ELEMENT birthdate (#PCDATA)> <!ELEMENT gender (#PCDATA)> <!ELEMENT socialsecuritynumber (#PCDATA)> Taking this line by line:people_list is a valid element name, and an instance of such an element contains any number of person elements. The * denotes there can be 0 or more person elements within the people_list element.person is a valid element name, and an instance of such an element contains one element named name, followed by one named birthdate (optional), then gender (also optional) and socialsecuritynumber (also optional). The ? indicates that an element is optional. The reference to the name element name has no ?, so a person element must contain a name element.name is a valid element name, and an instance of such an element contains "parsed character data" (#PCDATA).birthdate is a valid element name, and an instance of such an element contains parsed character data.gender is a valid element name, and an instance of such an element contains parsed character data.socialsecuritynumber is a valid element name, and an instance of such an element contains parsed character data.An example of an XML file that uses and conforms to this DTD follows. The DTD is referenced here as an external subset, via the SYSTEM specifier and a URI. It assumes that we can identify the DTD with the relative URI reference "example.dtd"; the "people_list" after "!DOCTYPE" tells us that the root tags, or the first element defined in the DTD, is called "people_list":<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE people_list SYSTEM "example.dtd"> <people_list>  <person>  <name>Fred Bloggs</name>  <birthdate>2008-11-27</birthdate>  <gender>Male</gender>  </person> </people_list> One can render this in an XML-enabled browser (such as Internet Explorer or Mozilla Firefox) by pasting and saving the DTD component above to a text file named example.dtd and the XML file to a differently-named text file, and opening the XML file with the browser. The files should both be saved in the same directory. However, many browsers do not check that an XML document confirms to the rules in the DTD; they are only required to check that the DTD is syntactically correct. For security reasons, they may also choose not to read the external DTD.The same DTD can also be embedded directly in the XML document itself as an internal subset, by encasing it within [square brackets] in the document type declaration, in which case the document no longer depends on external entities and can be processed in standalone mode:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE people_list [  <!ELEMENT people_list (person*)>  <!ELEMENT person (name, birthdate?, gender?, socialsecuritynumber?)>  <!ELEMENT name (#PCDATA)>  <!ELEMENT birthdate (#PCDATA)>  <!ELEMENT gender (#PCDATA)>  <!ELEMENT socialsecuritynumber (#PCDATA)> ]> <people_list>  <person>  <name>Fred Bloggs</name>  <birthdate>2008-11-27</birthdate>  <gender>Male</gender>  </person> </people_list> Alternatives to DTDs (for specifying schemas) are available:XML Schema, also referred to as XML Schema Definition (XSD), has achieved Recommendation status within the W3C,[8] and is popular for "data oriented" (that is, transactional non-publishing) XML use because of its stronger typing and easier round-tripping to Java declarations.[citation needed] Most of the publishing world has found that the added complexity of XSD would not bring them any particular benefits,[citation needed] so DTDs are still far more popular there. An XML Schema Definition is itself an XML document while a DTD is not.RELAX NG, which is also a part of DSDL, is an ISO international standard.[9] It is more expressive than XSD,[citation needed] while providing a simpler syntax,[citation needed] but commercial software support has been slow in coming.Security[edit]An XML DTD can be used to create a denial of service (DoS) attack by defining nested entities that expand exponentially, or by sending the XML parser to an external resource that never returns. For this reason, .NET Framework provides a property that allows prohibiting or skipping DTD parsing, and recent versions of Microsoft Office applications (Microsoft Office 2010 and higher) refuse to open XML files that contain DTD declarations”.