Third-party parcels shouldn't be in a namespace beginning with "http://osafoundation.org/";. There are few rules and conventions about what goes into namespaces but that's one of them -- only the organization responsible for the domain in the URI (if there is a domain part) should create a new namespace with that domain or new elements in such a namespace, or that organization must coordinate the creation of namespaces or elements in those namespaces. Since namespaces exist to disambiguate XML names (QNames) and avoid collisions, making people re-use a namespace we've already defined weakens that at least conceptually.
Then maybe we shouldn't be using XML namespaces. :)
Seriously though, please note that the current parcel loader implementation doesn't support getting its uniqueness from the XML namespace anyway. If you have two parcels whose directory paths begin with "myparcel", the existing implementation will barf anyway, because it will try to give them the same repository path. This issue is similar to the Python uniqueness requirement (see below), but is independent since it can effect even parcels without any Python code whatsoever.
Do Python package paths have uniqueness requirements? E.g. is it impossible to find a package called /mypackage in more than one location?
It's not possible unless you actively manipulate the package's __path__ attribute, and even then there are some limitations.
What I'm proposing is that since parcel schemas will in future mainly be defined by Python code, and since Python modules have to be unique to begin with, trying to get people to *also* come up with an XML namespace is just busywork; a unique XML namespace isn't going to fix a collision occurring at the directory-name level, so slapping the package name into an OSAF-defined namespace will not create any new collisions.
Therefore, the *real* namespace definition (IMO) is the parcel's Python package or module name, and the fact that we spell that name in XML by turning dots to slashes and prepending 'http://osafoundation.org/parcels/' is a mere implementation detail -- one that could possibly go away altogether, depending on how the evolution of the parcel.xml format proceeds once the schema API is in place.
The reason I say it's the "real" namespace definition is that it's the way that people writing parcels will access definitions from other parcels. So, to depend on a parcel or use it from Python, you'll pretty much *have* to know its dotted name, and over time all of the "slashed" forms of the names (as namespaces and repository paths) can fade away, so that you only need to know *one* way to spell a given parcel's name. This would be a significant improvement over the current state of affairs, where the same thing can be:
* http://osafoundation.org/parcels/osaf/contentmodel * osaf.contentmodel * //parcels/osaf/contentmodel
...depending on precisely what you're trying to do with it. Currently, the first of these items is also allowed to be arbitrarily different from the other two, such that you can't find out what it is by looking at one of the others, or vice versa! From a parcel developer's point of view, that's just broken.
In fact, I'd almost suggest that the differences between them be further reduced, by making them look like this instead:
* http://osafoundation.org/parcels/osaf.contentmodel * osaf.contentmodel * //parcels/osaf.contentmodel
IOW, one can simply prepend a prefix to the package name to create a namespace URI or repository path. Since there's no inherent need for either the namespace URI or the parcels in the repository to be hierarchical (at least AFAIK), this would simplify mechanical translation and also make the central role of the package name more apparent.
However, in the short term (e.g. 0.6), I'm not sure the benefit of the change would outweigh the potential disruption, so I don't think we need to consider this more agressive change until after all of Chandler's parcel schemas are using the new API. At that point, it should be a lot more clear what the impact of such a change would be.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
