Menu Spec: including files & absolute paths

Waldo Bastian 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
> 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.

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050323/c01d72e9/attachment.pgp 


More information about the xdg mailing list