[Dev] Parcel namespaces and the schema API

John Anderson john at osafoundation.org
Wed May 11 15:26:18 PDT 2005

Thanks for correcting me on the fact that the majority of parcels don't 
contain Kinds. After thinking about it more I think what I should have 
said is that I suspect the majority of Items added to the repository are 
Instances, not Kinds -- today those Items happen to fall into a few 
parcels, e.g. parcels/osaf/views. Kinds are spread out into more parcels.

I think the distinction between Kinds and Instances makes sense (but not 
the distinction between UI Items and non-UI Items). I also agree with 
Morgen's comment that we need a way for Items to refer to other Items 
and to me it seems like this shouldn't require a Python module since 
it's data referring to other data, not code.

Personally I don't care what format we use for getting Items into the 
repository -- as long as it's easy to use and it only populates an 
initial repository with data. It's also important to be able to export 
data in the repository in a format that can be later imported -- and 
it's desirable if that wasn't yet another format to learn. This will 
come in handy some day when we're able to edit the Items in the 
repository using the UI and be able to export them as parcels.


Phillip J. Eby wrote:

> 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.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev

More information about the Dev mailing list