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