User Tools

Site Tools


design:finalizer

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
design:finalizer [2015/05/13 12:18]
paul Added rfc/@scripts
design:finalizer [2015/05/22 15:07] (current)
paul Added warning that the page is out of date.
Line 1: Line 1:
 +**THIS PAGE IS NO LONGER IN USE AND IS OUT-OF-DATE.**
 +
 +**PLEASE SEE draft-hoffman-rfcv3-preptool INSTEAD**
 +
 ===v3 prep tool usage scenarios=== ===v3 prep tool usage scenarios===
  
Line 14: Line 18:
 ==Internet-Draft submission== ==Internet-Draft submission==
  
-When the IETF draft submission tool accepts v3 XML as an input format, the submission tool runs the submitted file through the prep tool. If the tool finds no errors, it keeps two XML files: the submitted file and the prepped file. The prepped file is used by the IETF formatters to create outputs such as HTML, PDF, and text (or the tools act in a way indistinguishable from this). The message sent out by the draft submission tool includes a link to the original XML as well as the other outputs, including the prepped XML.  +When the IETF draft submission tool accepts v3 XML as an input format, the submission tool runs the submitted file through the prep tool. If the tool finds no errors, it keeps two XML files: the submitted file and the prepped file
 +This prepped file represents a self-contained record of what any external references resolved to at the time of submission. The prepped file is used by the IETF formatters to create outputs such as HTML, PDF, and text (or the tools act in a way indistinguishable from this). The message sent out by the draft submission tool includes a link to the original XML as well as the other outputs, including the prepped XML.  
  
-The prepped XML can be used by tools not yet developed to output new formats that have as similar output as possible to the current IETF formatters.  For example, if we create a .mobi output renderer later, we can run that renderer on all of the prepped XML that we have saved, ensuring that all of the part numbers and boilerplate we be the same as produced by the previous IETF formatters at the time the document was first uploaded.+The prepped XML can be used by tools not yet developed to output new formats that have as similar output as possible to the current IETF formatters.  For example, if we create a .mobi output renderer later, we can run that renderer on all of the prepped XML that we have saved, ensuring that the content of included external references and all of the part numbers and boilerplate will be the same as what was produced by the previous IETF formatters at the time the document was first uploaded.
  
 ==Canonical RFC preparation== ==Canonical RFC preparation==
Line 34: Line 39:
   * Fill in document publish date   * Fill in document publish date
   * Fill in expires date, if in I-D mode   * Fill in expires date, if in I-D mode
-  * Fill in "scripts" attribute for ''<rfc>''. 
   * Fill in any default values for attributes on elements, except t/@keepWith* and section/@toc   * Fill in any default values for attributes on elements, except t/@keepWith* and section/@toc
   * If the ''<workgroup>'' item doesn't end with "Group", warn   * If the ''<workgroup>'' item doesn't end with "Group", warn
Line 46: Line 50:
     * figure: ''pn='f-4'''     * figure: ''pn='f-4'''
     * (abstract, note, t, aside, blockquote, li, dt, artwork, sourcecode, references): ''pn='p-[section]-[counter]'''     * (abstract, note, t, aside, blockquote, li, dt, artwork, sourcecode, references): ''pn='p-[section]-[counter]'''
-  * add start attribute to every ''<ol>'' element containing a group that doesn't already have a start. +  * Add start attribute to every ''<ol>'' element containing a group that doesn't already have a start. 
-  * sort refs, if desired+  * Sort the references, if desired
   * Resolve all ''<xref>'' elements   * Resolve all ''<xref>'' elements
     * Ensure the target is valid     * Ensure the target is valid
Line 56: Line 60:
       * Check SVG schema against our TinySVG profile       * Check SVG schema against our TinySVG profile
     * else if ''src'' != ''data:'', turn into ''data:'', insert xml:base     * else if ''src'' != ''data:'', turn into ''data:'', insert xml:base
-  * Add ''rfc/@finalizedTime'' attribute+  * Add finalizedTime to attribute to ''<rfc>''
 +  * Add a ''<link>'' to ''<rfc>'' for the DOI, if this is an RFC. 
 +  * Determine all the characters used in the document and fill in "scripts" attribute for ''<rfc>''
 +  * Ensure that the output has the "version" attribute of ''<rfc>'', and that it is set to "3"
   * Pretty-format the XML output.  Note: [[https://github.com/hildjj/dentin|Dentin]] now does an adequate job.   * Pretty-format the XML output.  Note: [[https://github.com/hildjj/dentin|Dentin]] now does an adequate job.
     * This step might be controversial     * This step might be controversial
   * Ensure full compliance to v3 schema, without any deprecated elements or attributes, and error if any issues are found   * Ensure full compliance to v3 schema, without any deprecated elements or attributes, and error if any issues are found
-  * Ensures that the output has the "version" attribute of ''<rfc>'', and that it is set to "3" 
design/finalizer.1431544731.txt.gz · Last modified: 2015/05/13 12:18 by paul