Menu Spec: including files & absolute paths
markmc at redhat.com
Thu Mar 24 13:00:21 EET 2005
On Thu, 2005-03-24 at 10:50 +0000, Matt Kynaston wrote:
> When an implementation updates an existing menu file it may need to
> update the identifier to a newer version of the DTD.
> This makes sense, and I think the wording is fine. But I'm wondering
> how a menu editor should actually handle upgrading. Let me try and
> Right now I'm always preserving the DTD of the original, since it
> seems the best indicator of what the system itself supports. I
> extract the version from the doctype's systemId so I can use it to
> test for things I can safely add (<MergeFile type="parent"> is a good
> That's fine, but it means that once created, the user menu will never
> get upgraded to a new DTD. What I'm thinking of doing is checking the
> DTD of the 'system' menu (ie /etc/xdg/menus/applications.menu) and
> always preserving that, upgrading the user menu if necessary.
> Is that a sensible interpretation?
No, you should just go ahead and always use <MergeFile type="parent"/>
and set the DTD to the DTD version which first introduced the new
In order to remain compatible with newer versions, implementations
should ignore and preserve any XML elements, attributes and attribute
values that it does not know how to handle.
is what allows you to use new stuff (so long as you reference the
correct DTD version), even if the implementation that's going to parse
it doesn't yet support that version of the DTD.
(Also, think about things like a homedir shared between multiple
distros/version of distros - you can't figure out the union of all the
DTD versions supported by all the implementations which might read
the .menu file you write out)
More information about the xdg