User Tools

Site Tools


design:xml-tags

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
Last revision Both sides next revision
design:xml-tags [2014/01/27 14:52]
paul [Lists]
design:xml-tags [2014/03/15 20:12]
paul Updated for -03
Line 15: Line 15:
 Extend the concept of language tagging to at least examples and contact information to address potential CJK font confusion. //No objections to this for v3 from rfc-interest. -00// Extend the concept of language tagging to at least examples and contact information to address potential CJK font confusion. //No objections to this for v3 from rfc-interest. -00//
  
-Include feedback information so that generated documents can provide usable feedback links.  //No objections to this for v3 from rfc-interest.//+Include feedback information so that generated documents can provide usable feedback links.  //Wondering how this is supposed to work: is it only for metadata, or is a processor supposed to turn it into text. If the latter, where in the RFC does the text appear? Need to take back to rfc-interest.//
  
 Make the <date> element optional; all of its content is optional already. //No objections to this for v3 from rfc-interest. -00// Make the <date> element optional; all of its content is optional already. //No objections to this for v3 from rfc-interest. -00//
Line 23: Line 23:
 =====  Contact Information ===== =====  Contact Information =====
  
-Add a mechanism for a ASCII fallback for non-ASCII names and addresses. Both forms should be searchable.+Add a mechanism for a ASCII fallback for non-ASCII names and addresses. Both forms should be searchable. //General agreement on this on rfc-interest. -03//
  
-Get rid of the restrictions in <postal>, and make it free text in order to better handle different styles of postal addressing throughout the world. //General agreement on this on rfc-interest.//+Get rid of the restrictions in <postal>, and make it free text in order to better handle different styles of postal addressing throughout the world. //General agreement on this on rfc-interest. -00//
  
 =====  Figures ===== =====  Figures =====
Line 33: Line 33:
 Remove anything that has to do with horizontal or vertical whitespace. Remove anything that has to do with horizontal or vertical whitespace.
  
-Extend <figure> to support different types of artwork.+Extend <figure> to support different types of artwork. //General agreement on this on rfc-interest. -01//
  
 ===== Floating Figures ===== ===== Floating Figures =====
Line 49: Line 49:
 Allow multiple paragraphs in a list item; eliminate the need to use <vspace>. //General approval of this idea from rfc-interest for v3. -00// Allow multiple paragraphs in a list item; eliminate the need to use <vspace>. //General approval of this idea from rfc-interest for v3. -00//
  
-Create a new list style for dictionaries. //General agreement on rfc-interest.//+Create a new list style for dictionaries. //General agreement on rfc-interest. -02//
  
 ===== References to Lists ===== ===== References to Lists =====
  
-Items that need to be discussed. //Under discussion on rfc-interest starting 2014-01-09//+Items that need to be discussed. //Short discussion on rfc-interest starting 2014-01-09, no conclusion//
  
-  - Ordered List ItemShould the reference value reflect the style, and in that case what is the correct reference value to use for each of the styles.+  - Should the reference value reflect the style, and in that case what is the correct reference value to use for each of the styles.
   - Should the reference value be built from the chain of list elements?   - Should the reference value be built from the chain of list elements?
   - Should it be possible to generate a reference that is a partial list of the chain of elements   - Should it be possible to generate a reference that is a partial list of the chain of elements
Line 63: Line 63:
 =====  References ===== =====  References =====
  
-Allow overriding the "anchor" attribute of an included <reference> element. //No objections to this for v3 from rfc-interest.//+Allow overriding the "anchor" attribute of an included <reference> element. //No objections to this for v3 from rfc-interest. However, this seems unlikely to work without Processor Instructions, which are being deprecated.//
  
 Add a way to add prose to a reference that avoids abuse of <seriesInfo>. //No objections to this for v3 from rfc-interest.// Add a way to add prose to a reference that avoids abuse of <seriesInfo>. //No objections to this for v3 from rfc-interest.//
  
-Allow <reference>s that identify a document set such as a multi-RFC BCP or a multi-document standard from another SDO. //Lots of discussion on how to do this for v3 on rfc-interest.//+Allow <reference>s that identify a document set such as a multi-RFC BCP or a multi-document standard from another SDO. //Lots of discussion on how to do this for v3 on rfc-interest. -02//
  
 Deprecate or remove the <format> element. One idea was to use new elements such as @rel; another is to just point to the main RFC Info page. //Lots of discussion on this for v3 on rfc-interest.// Deprecate or remove the <format> element. One idea was to use new elements such as @rel; another is to just point to the main RFC Info page. //Lots of discussion on this for v3 on rfc-interest.//
Line 75: Line 75:
 In v2, there are a few elements that require their sub-elements to be in a certain order even though that order isn't really needed by the XML processor. For example, <address> requires the enclosed <postal>, <phone>, <facsimile>, <email>, and <uri> elements be in exactly that order. Given that each sub-element has its own name, the order should not be important. //A few questions about how the current processors work, but no objections to this for v3 from rfc-interest. -00// In v2, there are a few elements that require their sub-elements to be in a certain order even though that order isn't really needed by the XML processor. For example, <address> requires the enclosed <postal>, <phone>, <facsimile>, <email>, and <uri> elements be in exactly that order. Given that each sub-element has its own name, the order should not be important. //A few questions about how the current processors work, but no objections to this for v3 from rfc-interest. -00//
  
-<spanx> has both a weird whitespace model ("preserve") and problematic styling.  Deprecate it, and in its place add <tt>, <b>, and <i>. //Not yet discussed on rfc-interest-00//+<spanx> has both a weird whitespace model ("preserve") and problematic styling.  Deprecate it, and in its place add <tt>, <b>, and <i>. //Not yet discussed on rfc-interest, but included in -00.//
  
 ===== Sections Without Numbers ===== ===== Sections Without Numbers =====
Line 84: Line 84:
  
 Maybe allow for xrefs to be used in the <ttcol> element.  It might also be reasonable to allow for iref and cref and eref and spanx to be used here as well. //No objections to this for v3 from rfc-interest. -00// Maybe allow for xrefs to be used in the <ttcol> element.  It might also be reasonable to allow for iref and cref and eref and spanx to be used here as well. //No objections to this for v3 from rfc-interest. -00//
 +
 +===== New Formatting =====
 +
 +Add a <blockquote> element. This is to be used for real quotes, not just for text that is indented from both left and right margins; there should be an ability to do the latter as well. //Added in -03//
design/xml-tags.txt ยท Last modified: 2014/03/17 08:57 by paul