[Dev] Proposal: simplify parcel XML namespaces

[Phillip J. Eby]

At 01:20 PM 6/27/2005 -0700, Ted Leung wrote:
>If we are seriously considering going to a domain specific XML for
>0.7, then I don't think its worthwhile to spend a lot ot time
>patching parcel.xml.

I'm fairly sure I've spent more time discussing the change than I will on 
implementing it.  For that matter, I will probably spend more time running 
the tests afterward.  ;)

Also, there are no specific proposals outstanding for a hypothetical 
domain-specific format.

Currently, almost 6000 of Chandler's 10000 lines of parcel.xml reside in 
osaf.framework.certstore.data, and almost half of the remaining 4000 lines 
are in osaf.views.main.  There are less than 40 parcel.xml files, with a 
median size of about 24 lines.  Only 7 parcel.xml files have more than 100 
lines of XML in them.  I think that this is a pretty good indication that 
the schema API has displaced most everything but UI and certain specialized 
data.

For specialized data like the certstore, I don't see that the parcel.xml 
format buys anything, since it's just an intermediate conversion 
format.  One might as well just directly import such data to the 
repository.  If I added my previously-proposed "create_parcel" hook, then 
certstore.data.__init__ could read something like this:

     def __create_parcel__(parcel):
         for filename in certificate_filenames:
             # ... read the file for info

             # create a certificate object w/parcel as the parent
             Certificate(name, parcel, type="root", trust=3, ...)

And then we could just dump the original certificate files into the 
certstore/data directory, rather than having to paste them into a 
parcel.xml file.  In other words, if the data source is already available 
in some computer-readable form, one might as well let it be loaded by code 
at parcel creation time.

(In fact, I anticipate that at some point the loading of parcel.xml files 
themselves will be done in similar fashion, albeit automatically rather 
than by defining a __create_parcel__ function.)

Anyway, this pretty much leaves the GUI use cases, and there could be a 
custom XML format for that, but so far I've only seen discussion of 
"something XUL-like" without getting much more specific.

I suspect, however, that there are some tweaks possible to the parcel.xml 
format that would alleviate its current issues for GUI definition.  These 
would be changes both to the parser (e.g. to allow nesting items as 
references), and to the actual schema (e.g. redefining many block types to 
separate interface from behavior, ala Eclipse UI delegates).  I would also 
like to establish some guidelines to clean up some of the naming conflict 
messes (where there are items with the same name as the class) and 
eliminate the need to use itemClass altogether.

But, these would be evolutionary changes rather than revolutionary, at 
least with respect to the parcel loader.  Honestly, unless somebody just 
puts together some really smashing idea for a GUI-specific XML syntax (and 
soon!), I think that minor improvements to the loader and the schema will 
be fine for getting us through 0.7 at the very least.