[Dev] Parcel namespaces and the schema API

[Phillip J. Eby]

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:

    * 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.