Menu Spec: including files & absolute paths
bastian at kde.org
Wed Mar 23 23:53:39 EET 2005
On Tuesday 22 March 2005 12:21, Mark McLoughlin wrote:
> On Mon, 2005-03-21 at 22:02 +0100, Waldo Bastian wrote:
> > On Monday 21 March 2005 18:12, you wrote:
> > > Perhaps we should drop the "stop processing on unknown" part, allowing
> > > implementations to just pass through unknown elements/attributes if
> > > they don't do full DTD validation?
> > Yes, because it makes future extensions impossible.
> Well, it doesn't really. As long as the menu file references the
> correct version of the DTD, it will remain valid even if we add
> extensions to later version. This is suggested down the page a little
> All menu files MUST include the document type declaration, so that
> implementations can adapt to different versions of this specification
> The problem for us is that we don't actually validate against the
> actual DTD specified in the menu file, but our own notion of the DTD,
> which is clearly broken.
> All fairly academic if the DTD isn't on the website, though :-)
> > Suggest to change
> > "implementations are expected to stop processing if they encounter XML
> > elements or attributes that are not specified in this document."
> > to
> > "In order to make extension of this specification possible in the future,
> > implementations are expected to ignore any XML elements or attributes
> > that are not specified in either the DTD or this document."
> So, I suggest
> Menu files must be well-formed XML files and end in the extension
> ".menu". They should also conform to the menu file DTD which implies
> that implementation-specific extensions to the file format are not
> allowed. Implementations may stop processing if they encounter a menu
> file which does not comply with the associated DTD.
> i.e. if an implementation validates against the DTD specified in the
> menu file, then they're within their rights to barf if the file doesn't
I have combined the above with my suggestion above to stress the fact that the
file should comply with the associated DTD _AND_ to make clear that this DTD
may in fact be a different version than what you may expect, with some rules
for what to do when you encounter a different DTD version.
Please check CVS if that looks ok, I haven't updated the website yet.
> > I also note that it says "System Identifier for 0.8" while the spec is at
> > revision 0.9 and soon 1.0, I guess we should update that to match the
> > actual version?
> Yep, maybe make the version number an entity at the top of the file so
> it only needs to be changed once in future.
Done. I do allow the spec version and dtd version to be different though,
because we may want to do small spec version updates (e.g. for
clearification) without actually changing the dtd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050323/c01d72e9/attachment.pgp
More information about the xdg