Interesting. Personally, I don't care for the #info aspect of the namespace.
Some background on #:
In RDF-land (where this idiom comes from), this is considered by a number of people as broken and I imagine it's quietly being deprecated over the last few years. It's good that people want to make readable URIs for the purposes of quick eyeballing, but the idea of algorithimically hacking into an opaque name by putting markers into it is dubious. It doesn't make things clearer that the strings we're using for XML Namespace /names/ are in fact /structures/ wrt the Web (but that's a long running and heated perma-thread in XML).
Personally, I don't encourage #fragid use in namespaces - you don't need fragment structure for (an opaque) name. Again personally, I would disagree with the Cocoon consensus. Mixing XML namespaces and document structures is a messy affair.
Beyond that, current practice seems to be focusing on the idea of putting time into names, not version numbers. So you have something like this:
http://www.apache.org/foo/bar/2004/05/22 http://www.apache.org/foo/bar/2004/05 http://www.apache.org/foo/bar/2004
That's useful insofar as it gives flexbility as to how to decide to upgrade physical schema wrt a version number. If you use version numbers you tie your names into the upgrade strategy of whatever versioning policies are in place. Possibly over time, that will not be what you want, given that versioning is just about a difficult problem as your are likely to find in this industry (it's right up there with naming and cache invalidation in my book).
For example, I do a lot of work with particular XML enveloping structure that has embedded "1.0" in its namespace. I dearly wish a date had been use as would have avoided interminable confusion and deadlock around what were non-breaking and editorial alterations to schema. "2001" would have been easier all round.
If the consensus here is to put version numbers into namespace names then I suggest that only the major number is inserted. I also suggest that a versioning policy be laid down first. But with dates you can defer such policy decisions and/or change them if required.
cheers Bill de h�ra
