[Dev] Parcel namespaces and the schema API

[Phillip J. Eby]

At 10:11 AM 5/11/2005 -0700, Katie Capps Parlante wrote:
>Phillip J. Eby wrote:
>>At 08:37 AM 5/11/2005 -0700, Lisa Dusseault wrote:
>>
>>>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.
>
>Perhaps "thirdparty" is not the right way to describe Zaobao. It is not a 
>core parcel but it was created and will continue to be maintained by OSAF, 
>as an example, at least for 0.6. (Of course we still need to address the 
>issue for 3rd party parcels).

Let me clarify: Zaobao was and is using an osafoundation.org namespace.  I 
only changed it so that it follows the '/parcels' convention rather than 
its idiosyncratic use of '/examples'.  So, the old Zaobao namespace root was:

     http://osafoundation.org/examples/zaobao

And I have changed this in CVS to:

     http://osafoundation.org/parcels/osaf/examples/zaobao

So that the portion following '/parcels' translates directly to 
'osaf.examples.zaobao', which is its Python package name.  This means that 
when the Schema API is integrated with the parcel loader, any 
Python-defined schema for Zaobao will be automatically loaded *before* a 
parcel.xml file attempts to create instances.  (All of the other parcels 
were already using this naming convention, but some parcels lacked an 
__init__.py to make them an importable package.)

This is why the issue is important; in order to integrate the schema API 
with the parcel loader, there needs to be a common -- or at least mutually 
translatable -- addressing mechanism.  With the Zaobao namespace change, 
and the checkin of empty '__init__.py' files for various parcels, the 
current CVS version of Chandler has a consistent 1:1 mapping between parcel 
namespaces and Python package names, so I can implement the schema 
API/parcel manager integration.  The integration will assume that all 
parcels with non-standard namespaces (i.e., those not beginning with
'osafoundation.org/parcels') do not contain any Python schema and will 
therefore not attempt to import the corresponding package.