[Dev] Parcel namespaces and the schema API
Phillip J. Eby
pje at telecommunity.com
Tue May 10 19:35:25 PDT 2005
At 06:04 PM 5/10/2005 -0700, Lisa Dusseault wrote:
>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:
...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
In fact, I'd almost suggest that the differences between them be further
reduced, by making them look like this instead:
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.
More information about the Dev