[Standards] "storage:*" namespaces
Jonathan Chayce Dickinson
chayce.za at gmail.com
Sun Aug 26 06:04:19 CDT 2007
I kinda like the *:*:*:*... namespaces. jabber:* and storage:* are
really exclusive to Jabber, and even if they are not any responsible
developer should Google a new namespace first anyway: name clashes, not
an issue. And they are short, concise, and *very* easy to remember.
The only real way I see them being used is that the URI ones are
self-describing, i.e. they refer to the XEP itself, which is nice,
because some newbie developer can pick up up an XML document and
instantly find the documentation. However, the *:*:*:*... namespaces
describe functionality straight away, e.g. jabber:client and
jabber:server, what could be more descriptive than that?
And changing the namespaces will break a lot of existing code. Badly
written code (like magic strings) which is unfortunately quite abundant
will require changes in more that one class/module/whatever.
So no, sorry, doesn't look like we can ditch the *:*:*:*... namespaces.
Too much depends on it.
Tomasz Sterna wrote:
> Dnia 20-08-2007, Pn o godzinie 10:14 -0600, Peter Saint-Andre
> napisał(a):
>>> Could you please explain what's so ugly in "storage:*"?
>> The same thing that was so ugly about jabber:* -- it's not a real URI
>> or URN.
>
> But at all... It's just a plain, string identifier. Whether it is "real"
> or not, it does its job of identifying a namespace.
>
>
>> At the least, going forward we should not use such monstrosities and
>> instead use real URNs.
>
> Sure. Using "real" URNs protects us from nameclashes. But besides that,
> I do not see any advantages with using "real" URNs.
>
>
>
--
jonathan chayce dickinson
ruby/c# developer
cell: +27741863698
email: chayce.za at gmail.com
jabber: moitoi at inflecto.org
<some profound piece of wisdom>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6974 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070826/7d5beae0/attachment.bin
More information about the Standards
mailing list