Peter Saint-Andre 2013-05-28 14:34:01 -06:00
parent 901c54a380
commit 767ca95260
1 changed files with 160 additions and 0 deletions

View File

@ -0,0 +1,160 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<title>Data Forms - Color Field Type</title>
<abstract>This specification defines how to publish fields in data forms that take color values. Color values are best edited using a color picker dialog, rather than manual input.</abstract>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2013 by the XMPP Standards Foundation (XSF).</copyright>
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the &quot;Specification&quot;), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.</permissions>
<warranty>## NOTE WELL: This Specification is provided on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
<liability>In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.</liability>
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at &lt;<link url='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>&gt; or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).
<type>Standards Track</type>
<spec>XMPP Core</spec>
<p>First draft.</p>
<section1 topic='Introduction' anchor='intro'>
Some applications require configuration of color values. Examples can be what colors to use for different situations in control applications.
There's up to this point no good way to publish color values in a &xep0004;.
Some applications provide parameters of type list-single enabling the user to choose a color from a list of colors. This only allows the user
to select from a small amount of colors, and doesn't provide any visual feedback of the actual color chosen.
Editing color values as color components or encoded strings is both impractical and unintuitive.
This document proposes a method to publish color field parameters in a way that allows clients to show a color picker dialog for the parameter
instead of forcing the user to enter an encoded color value. For clients not supporting this extensions, the color value will still be editable
as an encoded color string.
This extension also relies on &xep0122; as a fall-back mechanism so clients not recognizing the color data type can handle it as a
string with a regular expression validating user input.
<section1 topic='Publishing a Color Field in a Data Form'>
The following example shows how to publish a Color Field parameter in a Data Form:
<example caption='Publishing a Color Field in a Data Form'>
<field var='color' type='text-single' label='Color:'>
<desc>Choose a color.</desc>
<xdv:validate xmlns:xdv='http://jabber.org/protocol/xdata-validate'
The color value is represented by a string consisting of six case-insensitive hexadecimal digits. The first two represent the red component,
the next two the green component and the last two the blue component.
If the client does not support XEP-0122 (Data Form Validation), it will interpret the field as a normal <strong>text-single</strong> field. It is
up to the server to validate user input. But the user can still enter a color.
A client that supports XEP-0122 (Data Form Validation), but not this extension, will not understand the data type <strong>xdc:Color</strong>.
It will thus default to a normal string (xs:string). However, the client still supports the <strong>regex</strong> validation rule,
making sure the client only allows user input that forms valid color values.
A client supporting this specification will recognize the <strong>xdc:Color</strong> data type, and choose to show a color picker dialog instead
of a string input field. In this case, the regular expression in the validation statement will not be used, as the string is not edited
directly by the user. However, it is still available implicitly in the xdc:Color data type.
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Color datatype prefix: xdc'>
As defined in <link url='http://xmpp.org/extensions/xep-0122.html#registar-reg-prefixes'>XEP-0122 §7.2.1</link>, following is the submission
to the XMPP Registrar of a new datatype prefix for use in data forms:
<code caption='Color datatype prefix: xdc'>
<desc>Defines the Color data type.</desc>
<section2 topic='Color datatype'>
As defined in <link url='http://xmpp.org/extensions/xep-0122.html#registar-reg-datatypes'>XEP-0122 §7.2.2</link>, following is the submission
to the XMPP Registrar of a new datatype representing color values for use in data forms:
<code caption='Color datatype'>
<desc>A color value represented as an RGB value.</desc>
<methods>basic regex</methods>
<section1 topic='XML Schema' anchor='schema'>
<?xml version='1.0' encoding='UTF-8'?>
<xs:simpleType name='Color'>
<xs:restriction base='xs:string'>
<xs:pattern value='^[0-9a-fA-F]{6}$'/>