Phillip J. Eby wrote:
At 03:35 PM 6/27/2005 -0700, Ted Leung wrote:
On Jun 27, 2005, at 2:12 PM, Phillip J. Eby wrote:
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. ;)
It's not the amount of time that concerns me, but the amount of churn
for developers. My previous comments were not intended as a veto,
just a mild statement of preference.
Makes sense. But there won't be any actual churn unless somebody 1)
comes up with another format, and 2) convinces John it's a good idea. :)
I don't have any problem with making changes parcel XML to make things
easier for developers as long as I can still create any schema and any
instance, not just U/I schema and instances. And, I'd like to get a
chance to obsolete it by doing a simple first crack at a GUI builder,
for which we'll need to have some format that we can both export and
import to the repository -- which would ideally be the same thing parcel
XML evolves into.
In the meantime, moving to a "parcel:" format for URIs will help me
get rid of most of our remaining parcel.xml files, and at least some
of the load-time overhead associated with them, as well as remove an
extra parsing pass from the parcel loader. Right now, implementing
the '<namespace>' element requires an extra parsing pass, but this
pass would not be necessary if all parcels have algorithmically-fixed
namespaces.
But, I can't get there without first changing the namespaces for all
the test parcels. Finally, I'd like the parcel loader to stop
requiring parent packages to have a parcel.xml in order for a child
package to have one. All of these things are a bit easier once the
parcel loader doesn't need to support arbitrary XML namespaces for
packages.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
