On 3/4/2009 12:29 PM, Peter Saint-Andre wrote:
On 3/3/09 9:26 PM, Brett Zamir wrote:
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.
Tempting for whom? Do you have a use case for this or are you simply
musing about the beautiful possibilities of namespaced attributes?
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.
Naturally, feel free to submit patches and bug reports to your favorite
xmpp code projects on to enable support for namespaced attributes. :)
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
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________
