[Dev] Parcel namespaces and the schema API

[Phillip J. Eby]

At 11:38 AM 5/11/2005 -0700, Katie Capps Parlante wrote:
>Phillip J. Eby wrote:
>  > Removing <namespace> is of course the potentially controversial bit, so
>>if you know of any reasons why it should remain, or have any input as to 
>>what the deprecation period before its removal should be, please 
>>respond.  Thanks!
>
>If I remember correctly, this was added for the convenience of xslt 
>processing. We were doing this to generate docs a while back, but we 
>haven't been doing that for some time. (Morgen uses the repository 
>directly instead). I'm in favor of removing it. +1

FYI, only two Chandler parcels besides Zaobao use it: 'core' and 
'osaf'.  (And I removed the usage from Zaobao because it was no longer needed.)

The only reason that core and osaf need it, is because the parcel manager 
doesn't provide a default namespace for top-level parcels.  But this is a 
one-line fix that I expect to make today, following which the two remaining 
<namespace> uses can be removed.


>As for the deprecation period -- the only factor I can see here is that it 
>would be nice if the sprint parcels worked with the trunk through the end 
>of May, so that we still have the option of using the trunk for demos of 
>these parcels in May.

So, should we have introduce a deprecation warning during that period 
(i.e., the parcel works but a warning appears on stderr), or should we use 
PendingDeprecationWarning instead and wait until the next milestone to 
introduce the DeprecationWarning?

(I'm making the projection/assumption here that we're following the Python 
language's conventions for informing developers that they're using 
deprecated features.  This may be overkill or underkill in Chandler's case, 
but it seems like a reasonable approach by default.)