If the namespace doesn't matter -- and I tend to agree -- then why not make the namespace we define our elements in be simply "http://osafoundation.org/namespace"; and let 3rd parties use their own namespace?
1. I'm not proposing changing the existing OSAF namespaces for anything but Zaobao; why needlessly churn the existing parcel.xml files? So, '/parcels' should remain our root namespace.
2. The purpose for which namespaces are currently used is to allow one parcel to refer to elements defined in another. Allowing third parties to choose their own namespaces means there are *two* things a parcel developer has to know for each parcel: its Python package name, and its arbitrary XML namespace. And, it is not possible to determine the XML namespace from the package name, or vice versa, if the XML namespace is allowed to be arbitrary.
Thus, allowing users to define their own namespace for parcel content identification produces needless overhead for parcel developers while providing no benefit. Therefore it should be eliminated.
Please keep in mind that unique URIs will not fix the fact that top-level parcel directory names must also be unique. If the directory names must be unique, then using them to form the URI will ensure uniqueness in a working system. In a system that's not working, it doesn't matter whether the namespace URIs are unique!
That is, if the system isn't working, the namespace URIs can be unique or collide, but either way the system is still non-functional. Thus, it makes no sense to worry about the URI collision, because fixing it doesn't fix the more stringent anti-collision requirement of directory uniqueness. It's closing the barn door after the horse has bolted, and it doesn't put the horse back in the barn.
The result of this is that our namespace *is* effectively managed by OSAF, just in an operational way rather than an administrative way. If you wanted to, you could insist that all parcels have a package name that includes the developer's domain, e.g. I would have to write parcels using 'telecommunity_com_foo' as the top-level package name. I personally think this is overkill, though.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
