On Fri, Aug 25, 2017, at 09:22, Dave Cridland wrote: > So the problem with that is that the schemas for the feature and the > (same-named) top-level element wouldn't match.
That seems fine to me, but I also don't understand XML schema so I might just not understand why that's a problem. How do other features handle this since they mostly use the same names? > On a similar note, however, you cannot design every stream feature > such that the negotiation method is to send the feature element as a > top-level element. Actual serious question: Why not? > I think it's reasonable to try to ensure that every stream feature's > namespace is the same as any top-level elements it uses; but that rule > has already been broken with dialback. I had forgotten about dialback; I'm not suggesting we change all old features though (nice as that would be), just that new ones try to stick to this rule. > I can spin up a server with this running if you like. That would actually be really nice; I've only tested against a server using the same implementation, so chances are mistakes wouldn't be noticeable. On Fri, Aug 25, 2017, at 09:27, Jonas Wielicki wrote: > it also may complicate implementations which map XML elements to > objects; they would then need context about where the element occurs to > pick the object to map it to. That's actually my use case, this is context you always have though. If I'm a server and I read from the connection expecting a stream feature to be selected, I know if I need to unmarshal into a request or response struct. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
