[jdev] Mixing Attribute Namespaces

[Brett Zamir]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20090304/f899b683/attachment-0003.htm>