Menu Spec: including files & absolute paths

Waldo Bastian bastian at
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
> with
> "
> 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
> validate.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 

More information about the xdg mailing list