<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> On 3/4/2009 12:29 PM, Peter Saint-Andre wrote: <blockquote cite="mid:49AE0399.7010300@stpeter.im" type="cite"> <pre wrap="">On 3/3/09 9:26 PM, Brett Zamir wrote: </pre> <blockquote type="cite"> <pre wrap="">Namespaced attributes are, imo, just too tempting to avoid using. Although it may go against the spirit of full present-day interoperability, I think implementations not supporting real namespacing are going against the spirit of XML--which is of course the /extensible /markup language--and should be the ones forced to adapt. </pre> </blockquote> <pre wrap=""> Tempting for whom? Do you have a use case for this or are you simply musing about the beautiful possibilities of namespaced attributes? </pre> </blockquote> Tempting for enhancing stanzas in ways which are interoperable for basic implementations and which offer advanced features or optimizations for other clients pending any standardization of the desired feature/optimization. There are any number of use cases. We have a specific need, but I can't go into it now--basically including meta-data which our client needs, which would otherwise require an additional query. For a non-optimization example, let's say we had a client which allowed users to send messages which could be considered to-dos for the other person. If the user wanted to indicate that a particular message they were sending should be considered as a to-do/reminder/tracked-item/etc. for the person sending it, they could add an attribute indicating such a type, without overloading the <message type> attribute. Yes, they could add a namespaced child element instead, in this case, but that is less appealing structurally-semantically and also not always feasible without more fundamentally altering the structure of the document, especially in specs which do not allow any freely namespaced children. An example of the latter might be if we wanted to allow text-private Data Form fields to indicate a default preference as to whether the client should display a control to allow temporary revealing of the private data/password, etc. Namespaced attributes should be pretty readily ignorable by modern implementations, unless they're doing the unlikely thing of validating against a (non-normative) schema which forbids all other attributes, while such attributes offer a chance for tweaking content oriented to specific clients' needs and features. Granted, in some cases, the (normative portion of the) spec explicitly forbids use of other attributes, such as on <subject/>, <status/>, etc. in RFC3921, but imo, I see this is an unfortunate restriction which I hope future versions will be able to lift. <blockquote cite="mid:49AE0399.7010300@stpeter.im" type="cite"> <pre wrap="">Naturally, feel free to submit patches and bug reports to your favorite xmpp code projects on to enable support for namespaced attributes. :) </pre> </blockquote> While I'm happy to make patches or suggestions in most cases, I would think such an implementation would need to start all over if it were parsing XML in a non-namespace-aware manner (and it would seem to me to be an odd strategy if they were namespace-aware yet cycling through all attributes to reject unknown ones), so I probably wouldn't be using such a project in the first place (and I'd probably only upset the project owners by making such a suggestion)! I wouldn't encourage other implementations to support our specifically namespaced attributes either, since it'd probably be better to try for standardization instead if there were wider interest in a specific attribute. Brett </body> </html>