Hello Lance
Thanks for your input. I'll respond to your concerns one at a time: Minor things I noticed: - The timestamp attribute. We've been using 'stamp' as the name for that type of attribute. Time stamp is otherwise a known and well-defined term. Stamp makes me think of snail mail. Is this important to change? - The type and level attribute values are currently title cased, but I personally prefer lowercase values since that is what is commonly used. Regarding casing it is actually a conscious decision to case enumerations, attributes and elements this way. I know many of the previous XEPs use other casing patterns and it may create some opposition, even though there are no guidelines regarding this to be found. So, let me motivate why I've used this type of casing: When XML was defined, it allowed element names and attribute names containing hyphens (-). This allowed people to define names where words are separated by hyphen signs and avoided previous methods like camel or Pascal Casing (camelCasing or PascalCasing could be replaced by camel-casing or Pascal-Casing for instance) capitalizing the first letter in each word (except perhaps the first word). This hyphenation is used in several XMPP elements and attributes. However, what they didn't think about (probably) was how this would play out when mapping XML to other constructs (like in code generation), or using expressions (like XPATH) or transformations using expressions (like XSLT, etc.). You can still use such names in XPATH, etc., as it is an XML technology, but you need to remember that the subtraction operator is now "fucked up" and cannot be used unless delimited with space characters. Worse is, when you want to map existing XML to other types of structures (for instance, using code generation tools, transforming a schema to C# for instance, as we often do). Then you would have to complicate matters taking special consideration if names were allowed to include symbols otherwise not allowed in the destination structure making each transformation tedious to make and error prone. So, first off, I try to avoid any hyphens in any names (element names, attribute names, enumerations). Instead I use either camel or Pascal Casing using only characters [a-zA-Z0-9_] (no digits as first character), as these can be mapped to almost any structure. The choice has then been made to use PascalCasing for element names and enumerations, and camelCasing for attribute names. It looks like those were made to match directly with syslog? One of the goals was to be able to easily map Syslog messages on-top of the structure defined in the XEP, without restricting the XEP to some of the deficiencies that exist in Syslog. There are several places where strict element ordering is mandated. Any particular reason why? Yes, it's because I want to be able to control allowed multiplicity of each element also in a simple way. Using choice constructs would only allow the user to select one element and its corresponding multiplicity. If you want to select multiple elements and control their individual multiplicities you need to allow a compound multiplicity, but cannot control the multiplicity of each individual element. Secondly, using sequences is more efficient in EXI compression since there are fewer options for next element in each step, requiring fewer bits to serialize. Best regards, Peter Waher
