Thu, 2 Mar 2017 22:41:31 +0100 Christian Schudt <[email protected]> wrote:
> I completely agree with your point and second this. I don’t even > think the schema for XEP-0030 allows any other elements although > Result Set Management extends disco#items as well. From a developer’s > point of view this only adds complexity and confusion to an > implementation. I'm agreed too. The problem arises when you move parsing code to a different level, i.e. you don't mess logic with parsing XML trees. Yes, I know, a lot of XMPP software is doing this, but I think this only produces shitty code and one of the problem why we cannot switch transport encoding (for instance, XML <-> JSON <-> Protobuff whatever). > It’s similarly confusing that a data form (jabber:x:data) can > apparently contain a roster (jabber:iq:roster) according to Example > 32 in XEP-0133, which is nowhere really documented. Exactly. I think that we should stop putting child elements inside "minor" elements, like this is also done in XEP-0158 (<media/> element inside <field/> element) and XEP-0377 (<report/> element inside <item/> element). More radical, I think only "jabber:*" namespace should be extensible. There is absolutely no need to extend other namespaces. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
