Select a syntax for hats.
Note: The format is open for debate. Possibilities include:
-XML element in the hats namespace with name as a URI:
-<hat xmlns='urn:xmpp:hats:0' name='http://tech.example.edu/hats#TeacherAssistant' display='Teacher's Assistant' xml:lang='en-us'/>
-Pro: Clients that don't understand the 'http://tech.example.edu/hats#TeacherAssistant' semantics can at least display a human-readable name. Names can be registered with the XMPP Registrar. Also appropriate as a field name in Ad-Hoc Commands.
-Con: Not a very Jabberish way of structuring information.
-XML element in the hats namespace with name scoped using Clark Notation:
-<hat xmlns='urn:xmpp:hats:0' name='{http://tech.example.edu/hats}TeacherAssistant' display='Teacher's Assistant' xml:lang='en-us'/>
-Pro: Clients that don't understand the 'http://tech.example.edu/hats#TeacherAssistant' semantics can at least display a human-readable name. Names can be registered with the XMPP Registrar. Also integrates well with Ad-Hoc Commands.
-Con: Not a very Jabberish way of structuring information.
-XML element qualified by custom namespace:
-<TeacherAssistant xmlns='http://tech.example.edu/hats' displayname='Teacher's Assistant' xml:lang='en-us'/>
-Pro: A more Jabberish way to structure information.
-Con: Clients won't show anything if they don't understand the custom namespace.
-As noted, a participant can wear many hats. The following example shows a participant who is a MUC room owner and both a "host" and a "presenter" in an online meeting system.
+Every hat is uniquely identified by its URI. Hats also carry a human-readable title for display purposes. Within XMPP, a hat is contained within a <hat/> element in the 'urn:xmpp:hats:0' namespace. This element MUST possess a 'uri' attribute (containing the hat's URI), a 'title' attribute containing the name of the hat for display purposes, and MAY contain an 'xml:lang' attribute that identifies the language used in the 'title' attribute. The <hat/> element MAY contain additional custom payloads defined by other XEPs, or payloads specific to an implementation or deployment.
+Entities may have multiple hats. The <hats/> element is defined as a container of zero or more <hat/> elements.
+ +As noted, a participant can wear many hats. The following example shows a participant who is a MUC room owner and both a "host" and a "presenter" in an online meeting system. This system also demonstrates how hats can be annotated with custom information (here, the example <badge/> element).