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
