[Dev] Parcel namespaces and the schema API

[Phillip J. Eby]

At 01:45 PM 5/11/2005 -0700, John Anderson wrote:
>I'm a little behind on reading this entire thread -- and maybe don't 
>understand the proposal very well -- however, we need a way for parcels to 
>contain only data (no code) and refer to data in other parcels, so if we 
>don't use name spaces to refer to other parcels, does that mean we use 
>Python modules? Most of the parcels that exist today (and I suspect in the 
>future) are data only

This isn't true; only 15 of Chandler's 36 parcel.xml files (as measured by 
"grep -c Kind `find parcels -name parcel.xml`") lack Kinds, which is 
actually less than half.  (And many of those files are empty "namespace" 
parcels whose child parcels contain all their items and schema anyway.)

Also, only three or so of the 36 needed an __init__.py added in order to 
make them modules; the other 33 were already Python packages.  In other 
words, 91% of Chandler parcels were already Python packages or modules to date.

As the package structure flattens, it's also likely that some of those 
now-empty parcel.xml files would be replaced with the contents of their 
child parcels, which would include schema.


>So I think it's a mistake to come up with two ways to populate items in 
>the repository,

We currently have three, actually: native XML, parcel XML, and 
Python.  Since we can't get rid of Python, to follow your advice we would 
therefore have to get rid of the XML.  That seems a bit more extreme than 
my position, although I don't necessarily think it's a bad idea.  :)

For specifying complex UI object graphs, it's possible that a specialized 
XML dialect could do a better job than a Python DSL (domain-specific 
language).  However, most other item creation use cases that I'm aware of 
(e.g. WakeupCallers, Currents, and such), a simple Python expression like 
the example I gave here:

     http://lists.osafoundation.org/pipermail/dev/2005-May/002904.html

seems to be far and away the best (i.e. simplest and most integrated) way 
for a hand-written parcel to add items.

Conversely, I think that repository native XML is the best way to export 
and import items not defined by hand-written parcels.  For now, I also 
think that sticking with parcel.xml to define UI items is a reasonable 
approach, but as Lisa has pointed out, the very generality of parcel.xml is 
a drawback from both a tools compatibility and usability perspective, 
compared to a fixed vocabulary or XML schema.  Such an XML dialect could 
also offer features optimized to make Chandler UI creation easier.