diff --git a/xep-0143.xml b/xep-0143.xml index 5ea92f49..f3cb4f54 100644 --- a/xep-0143.xml +++ b/xep-0143.xml @@ -11,6 +11,7 @@ &LEGALNOTICE; 0143 Active + Procedural Standards Council @@ -21,6 +22,12 @@ N/A &stpeter; + + 1.1rc1 + 2010-02-12 + tm +

Use of definition list for glossary, best practice on table usage and reminder on PDF publications.

+
1.0 2004-12-09 @@ -109,8 +116,9 @@

Aside from the metadata in the <header/> element (see above), a XEP file is a series of sections, arranged in a hierarchy (<section1/> is a top-level section, within which you can nest <section2/> sections, and so on down to <section4/>). The title of a section is captured in the 'topic' attribute. You should also include an 'anchor' attribute so that you can link to page fragments from within your document. The allowable elements within a section element probably look familiar from XHTML: <p/> for paragraphs, <ol/> and <ul/> for ordered and unordered lists, and so on.

The <example/> and <code/> elements are used to show protocol snippets; the <example/> element SHOULD possess a 'caption' attribute that describes the example, whereas the <code/> element does not. Define an XML CDATA section within both of these elements so that you do not need to escape the '<' and '>' characters in your sample XML stanzas, since this makes life much easier for author and editor alike (see the markup in existing XEP specifications).

The <p/> and <li/> elements can also contain more markup that is familiar from XHTML, such as the <img/> element. Note that hyperlinks are of the form <link url='foo'>bar</link> rather than <a href='foo'>bar</a>; the reasons for this are lost in the mists of time and it is too late to change it now, so you'll just have to adjust. If needed, you can also use inline structural and presentational markup such as <em/>, <strong/>, <tt/>, <cite/>, and <span/> within the <p/> and <li/> elements.

-

You may also include tables (these are helpful for listing error codes and such). The <table/> element SHOULD possess a 'caption' attribute that describes the table's contents. Standard XHTML table structure applies (<tr/> defines a row, which contains <th/> elements for header rows and <td/> elements for data rows), and the 'colspan' and 'rowspan' attributes are also available if you need them. Table presentation (such as cellpadding and cellspacing) is handled by the XSLT and CSS stylesheets.

+

You may also include tables (these are helpful for listing error codes and such). The <table/> element SHOULD possess a 'caption' attribute that describes the table's contents. Standard XHTML table structure applies (<tr/> defines a row, which contains <th/> elements for header rows and <td/> elements for data rows), and the 'colspan' and 'rowspan' attributes are also available if you need them. Table presentation (such as cellpadding and cellspacing) is handled by the XSLT and CSS stylesheets. However keep in mind that tables weren't mend to display huge amount of text.

In fact, the xep.xsl file performs all sorts of magic in converting your XML file into HTML, including creation of the front matter, table of contents, section numbering, notes, and revision history. Feel free to submit patches for this file, but do not commit your modified version to source control.

+

While HTML being the primary publishing format for XEPs, the XSF Editor also publishes XEPs in form of PDF since 2010. Keeping that in mind you should try to avoid tables with too much columns which require more width available on paper.

@@ -130,6 +138,7 @@

If your XEP document uses terms that may not be familiar to the reader, please define them in a glossary.

+

The preferred layout for a glossary is a definition list using the HTML <dl>-tag.

It is recommended that document authors structure their proposals according to the use cases that the proposal will address. A good introduction to use cases may be found at <http://www.pols.co.uk/usecasezone/>. We have found that use cases force authors to focus on functionality rather than "protocol for the sake of protocol". It is also helpful to sort use cases by actor, as is done in &xep0045;, for example. Include one subsection for each use case.