Both sides previous revision
Previous revision
Next revision
|
Previous revision
Last revision
Both sides next revision
|
design:xml-tags [2014/01/25 15:14] paul [Remove from v2 Vocabulary] |
design:xml-tags [2014/03/15 20:12] paul Updated for -03 |
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// |
===== 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 ===== |
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 ===== |
===== Lists ===== | ===== Lists ===== |
| |
Allow multiple paragraphs in a list item; eliminate the need to use <vspace>. //General approval of this idea from rfc-interest, particularly for making list items have their own element type.// | 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 |
===== 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.// |
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 ===== |
| |
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// |