Third message, third same reply mistake. I know: I am stupid. ---------- Forwarded message ---------- From: Jehan Pagès <jehan.marmottard at gmail.com> Date: Thu, Sep 24, 2009 at 8:01 PM Subject: Re: [xmpp] Fwd: Use of namespace in RFC 3920 To: Remko Tronçon <remko at el-tramo.be> Hi, 2009/9/24 Remko Tronçon <remko at el-tramo.be>: >> That's indeed what I am doing. Right now XMPP is not really following >> XML rules. It made new ones, and make it more difficult. > > As far as i remember, XMPP is following XML rules, but only made them > stricter, such that the parsers were simpler (i.e. didn't have to deal > with full XML spec). This implies that the serializers have to play by > some rules (which isn't so bad, since serializing doesn't necessarily > need an XML library). > you are right. But I think this may have been considered simpler some time ago, maybe depending on the state of the art of XML parsers and serializers at that time. But nowaydays, it does not look to me that these XMPP particularities make parsing/serialization really simpler or better than the basic XML way. Or maybe I don't see the point. I am not an expert of all what has been done on XML and on all the kind of optimizations that can be done. Just as of for now, I don't see how easier/faster/better these particularities make XML parsing, nor serialization, compared to the more general way of XML. f you have any link about how some of your implementations may use such namespace particularities of XMPP to optimize parsing or serialization, I would be happy to read on. Maybe there can be something that I don't get, and then I may understand better your reticence to change. For my own, the XML I send still follow these rules anyway. But what bothers me the most is that we are asked (some MUSTs), or encouraged (some SHOULDs), to reject some well-formed (in the meaning of XML namespace) and valid XML, even though it corresponds to XMPP DTD. This is why it does seem more like a patch on the RFC (instead of on codes) to make developper's life easier (or not: for me, not even). That's does not look like the best way. > I don't really see why you would need to modify your XML parser to > handle XMPP if it can handle XML, but maybe I'm missing something. > In fact when I parse the XML stream, I just keep the namespace context, but I remove the namespace prefix declarations and default namespaces after having used the information for expansion. At the time I was writing the XML parser, it was looking the cleaner way because the (default and prefix) ns declarations are not meaningful attributes outside of name qualification. So they become just useless (if not attribute pollution) once the namespace expansion has been done. Then I wrote the XMPP parser based upon my XML parser, hence the XMPP parser gets the qualified name directly. I could change it of course and let the ns declarations into the attributes. It is not as though it was particularly difficult. But then I add an additional, though useless, complexity (check not only the qualified names, but also how they have been qualified) to my XMPP parser + the fact that I still don't see any reason for this + the fact that I will be refusing well-formed and valid XML (so by principle, it is also annoying: XMPP namespace usage are not following the W3C recommandations). Bye. Jehan
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.