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