On 27 February 2015 at 08:28, Hund, Johannes <[email protected]> wrote: > Hi, > > this question comes from a recent discussion we had internally. > We try to identify a best practice/convention when designing several > somewhat-related extensions, specifically the naming of top-level elements in > IQs. > > It is noticeable that older, core-related XEPs (roster, disco etc.) use the > convention of elementName "query" and namespace according to extension > protocol.
Yes, <query/> is historic. > There was also the query action XEP-0099 which described a CRUD-pattern on > IQ-query, but got deferred. > It feels a bit odd to have a IQ set named "query", but apart from that, it > helps to expect what you get in implementing. > I have seen some implementations that offer comfort accessors to this pattern > (think it was strophe). I think any API that assumes the payload tag name is "query" is quite wrong. Something like IQ(type, namespace, tag) would be sensible. > Newer XEPs seem to use one top-element name according to protocol (pubsub, > si, jingle) and have sub-elements in own namespaces that deal with specific > aspects. These protocols all commonly have multiple child elements within the parent tag, which is one reason for them being how they are. But again, I think this pattern is not as favourable nowadays. > Also you see that some protocol extensions use several top-elements with the > same namespace rather than a singular one, diverging the aspect on the > element name. I think this is the approach most modern XEPs take. The resultant stanzas are more compact. > One could also design protocol extensions that use different elements and > namespaces individually for its use case. > > All is valid XML and XMPP and seemingly used. > The Guidelines in XEP-0134 and XEP-143 do not cover this. > > The thought is: > Would it make sense to give some guideline/convention on how to design the > schema, e.g. to name the payload child of an IQ, when to use a different > namespace etc.? I think some guidelines wouldn't be a bad thing for new XEP authors. > It could potentially make things more uniform, thus additionally allowing > helper functions in implementations and increase reuse? > Of course you could still vary from that convention, if you have some reason > to do so. Agreed. Regards, Matthew
