Mon, 4 Dec 2017 09:29:41 +0100 Florian Schmaus <[email protected]> wrote:
> That is what we always did when extending XMPP in a backwards > compatible way. I'm not aware of a case where we did something > different. And given that we want to avoid namespace bumps whenever > possible, I'm happy with that. Even if it means that live schema > validation is not feasible. Well this approach is wrong. Why would we need other namespaces then? We can put everything inside 'jabber:client'. Or, otherwise, what stops me from putting my own invented elements (and attributes) inside existing registered namespaces? Do we really need this mess? > Serous question: I wonder where do you see the benefit in schema > validation? You (always) need a parser which ensures that protocol > requirements like "this attribute must exist", or "this attribute must > be a uint32_t" are fulfilled. I have this validator in ejabberd, yes. And if it's enabled, the stanza with <retry/> element will be rejected. And I consider this as a correct behaviour. > And you want to enforce a maximum top-level stream element size early > in the processing chain. I didn't understand the stuff about top-level stream element size, how this relates to validation? > But if you have that, what is the gain in validating against a schema? Have what? Again, in my case server validation is needed to avoid sending garbage to clients (i.e. x='abc' when it should be an integer). _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
