new dtd - mkdir element

Mark Ellis mark.uzumati at
Wed Nov 14 13:23:57 PST 2001

On 2001.11.14 20:03 Jay Bennie wrote:
> 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? 
> Jay

I actually agree, i like the version that enforces positioning, and i think
a strong dtd is "a good thing", but since the new synatx is in the early
stages it needs feedback.

In answer to your question, that's just the way a dtd works. Your variation
is saying the first sub-element _has_ to be dir, which can be followed by
either a single base or mode element, or base or mode followed by mode. So
dir mode mode would be perfectly legal according to this dtd fragment, but
nonsense in alfs terms. Dir base base would be invalid, but equally so
would mode base dir.

There is actually a more flexible XML Schema, but i get the impression it's
quite young, and i don't know of anything that actually uses it yet, not
that i've had a good look. When and if it catches on however, it will
actually solve this kind of problem.


> ------------------------- 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
> |
> mode))>
> 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 ?
> Mark
> -- 
> Unsubscribe: send email to listar at
> and put 'unsubscribe alfs-discuss' in the subject header of the message
Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list