On May 11, 2005, at 10:11 AM, Katie Capps Parlante wrote:
Not that there's any rush on this anyway and probably not a 0.6 priority -- I was just responding to some design implications.Phillip J. Eby wrote:
2. The purpose for which namespaces are currently used is to allow one parcel to refer to elements defined in another. Allowing third parties to choose their own namespaces means there are *two* things a parcel developer has to know for each parcel: its Python package name, and its arbitrary XML namespace. And, it is not possible to determine the XML namespace from the package name, or vice versa, if the XML namespace is allowed to be arbitrary.
Thus, allowing users to define their own namespace for parcel content identification produces needless overhead for parcel developers while providing no benefit. Therefore it should be eliminated.
Yeah, I agree with this -- just creates more pain.
But, is it possible that we don't need new namespaces anyway? It's possible to define our XML schema used in parcel definition, such that any element or attribute used in parcel definition files would come from our definition format, thus these could all appear in a single namespace. Then, we could set it up such that 3rd party parcels never defined new element or attribute names, just new data.
However, note that this is definitely a rehashing of old arguments (and a sign of my obsession over things like namespace). Morgen & I looked at this a year ago and tried to remove the need for a 3rd party parcel to define any new XML element or attribute names. It got a little awkward to clean this up -- the "hack" I perceived made the syntax simpler once you grokked the hack. It's related to another "hack" which is to use namespace prefixes inside attribute values -- another XML namespace usage no-no. Now that we're making parcel definition changes, it may be much easier to avoid using namespaces and prefixes at all when referring to stuff inside another parcel.
Lisa
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
