new dtd - mkdir element

Jay Bennie jay at
Wed Nov 14 12:03:02 PST 2001

one of this issues that could spell the doom of this project is the overflexibility of the element definitions, is it not better to enforce the structure, there for providing a situation which is known to be stable allowing for optionality only where optionality really exists?

i.e I'm no expert in XML but what about this?
 (Simply keeping optionals at the end)

<!ELEMENT mkdir ( dir, (base | mode)?, mode?)>

I have noted that you said the attribs needed to be in order, may i ask why?  

PS. it may not be relevant to have a validating dtd at this point, but it may be in the future. Should the question not be how soon would we need a validating dtd? and why? 


------------------------- Original message --------------------------------------


And just to see if i can wake anyone up, back to something i mentioned
earlier, about the dtd dictating the order of elements. I'm in a quandry so
i'll spell out the options.

This  is what i started with, for example using <mkdir> :-

<!ELEMENT mkdir (base?, dir, mode?)>
This says mkdir has an optional element base, a compulsory dir, an optional
mode, and each can appear no more than once. Sounds perfect, unfortunately
they have to be in that order or it's not valid. I then thought of :-

<!ELEMENT mkdir (base | dir | mode)*>

This says the three sub-elements can appear in any order, however it also
says you can have any or all of them in any quantity, for instance six
bases and no dirs, which obviously makes no sense. Next we have :-

<!ELEMENT mkdir ((base | dir | mode)?, (base | dir | mode)?, (base | dir |

So we can have between one and three sub-elements, in any order, however,
they can be of any combination, so you can still have 3 bases and no dirs.
And that is as good as it gets. We can either have freedom without proper
validation or validation with a more constrained syntax.

I should point out again that this has very little effect on backends, it's
just to do with defining a dtd for the syntax, if we're not bothered about
a validating dtd it doesn't matter at all. Any thoughts ?

Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the alfs-discuss mailing list