moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-22 07:38:52 -05:00
Code Issues Releases Wiki Activity

XEP-0122: Remove unnecessary normative wording

Browse Source 
regarding the emptiness of elements. There is no point having that,
it just prevents potential (but unlikely) future extensions and adds
additional noise to the text.
This commit is contained in:
Florian Schmaus 2018-03-21 09:36:14 +01:00
parent d08a9c3e7c
commit 48858f1790
1 changed files with 7 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
xep-0122.xml
View File

@ -26,6 +26,12 @@
<registry/>
&linuxwolf;
<revision>
<version>1.0.2</version>
<date>2018-03-21</date>
<initials>fs</initials>
<remark>Remove text about element emptiness.</remark>
</revision>
<revision>
<version>1.0.1</version>
<date>2018-03-05</date>
<initials>fs</initials>
@ -142,7 +148,6 @@
</field>
]]></example>
<p>Using &lt;basic/&gt; validation, the form interpreter MUST follow the validation rules of the datatype (if understood) and the field type.</p>
<p>The &lt;basic/&gt; element MUST be empty (i.e., not contain any character data or child elements) and MUST NOT possess any attributes.</p>
</section3>
<section3 topic='&lt;open/&gt; Validation' anchor='usercases-validation.open'>
<p>For "list-single" or "list-multi", to indicate that the user may enter a custom value (matching the datatype constraints) or choose from the predefined values, the &lt;validate/&gt; element shall contain an &lt;open/&gt; child element:</p>
@ -160,7 +165,6 @@
</field>
]]></example>
<p>The &lt;open/&gt; validation method applies to "text-multi" differently; it hints that each value for a "text-multi" field shall be validated separately. This effectively turns "text-multi" fields into an open-ended "list-multi", with no options and all values automatically selected.</p>
<p>The &lt;open/&gt; element MUST be empty (i.e., not contain any character data or child elements) and MUST NOT possess any attributes.</p>
</section3>
<section3 topic='&lt;range/&gt; Validation' anchor='usercases-validation.range'>
<p>To indicate that the value should fall within a certain range, the &lt;validate/&gt; element shall contain a &lt;range/&gt; child element:</p>
@ -178,7 +182,6 @@
<p>The 'max' attribute specifies the maximum allowable value. This attribute is OPTIONAL. The value depends on the datatype in use.</p>
<p>The 'min' attribute specifies the minimum allowable value. This attribute is OPTIONAL. The value depends on the datatype in use.</p>
<p>The &lt;range/&gt; element SHOULD possess either a 'min' or 'max' attribute, and MAY possess both. If neither attribute is included, the processor MUST assume that there are no range constraints.</p>
<p>The &lt;range/&gt; element MUST be empty (i.e., not contain any character data or child elements).</p>
</section3>
<section3 topic='&lt;regex/&gt; Validation' anchor='usercases-validatoin.regex'>
<p>To indicate that the value should be restricted to a regular expression, the &lt;validate/&gt; element shall contain a &lt;regex/&gt; child element:</p>
@ -192,7 +195,7 @@
</field>
]]></example>
<p>The XML character data of this element is the pattern to apply. The syntax of this content MUST be that defined for POSIX extended regular expressions<note>The "best" definition of this syntax can be found in the <link url='http://www.gsp.com/cgi-bin/man.cgi?section=7&amp;topic=re_format'>re_format(7) man page</link></note>, including support for Unicode<note>Guidelines for adapting regular expressions to support Unicode is defined at <link url='http://www.unicode.org/reports/tr18/'>http://www.unicode.org/reports/tr18/</link></note>.</p>
<p>The &lt;regex/&gt; element MUST contain character data only (i.e., not contain any child elements) and MUST NOT possess any attributes.</p>
<p>The &lt;regex/&gt; element MUST contain character data only.</p>
</section3>
</section2>
<section2 topic='Selection Ranges in "list-multi"' anchor='usecases-ranges'>