new dtd

Mark Ellis mark.uzumati at
Wed Nov 14 10:47:37 PST 2001

On 2001.11.13 15:45 Neven Has wrote:
> On Mon, Nov 12, 2001 at 11:28:12PM +0000, Mark Ellis wrote:
> > Time to come up with an element name then eh ? <options> isn't bad, or
> > <flags> maybe ? And what values ? "Force" for link, copy, and move
> > obviously, can't decide whether link type would be better left by
> itself or
> > put with the other options. Possibly best left separate as a type
> should
> > really be mandatory, not optional, but see the answer below for more on
> > this.
> I think it's best that we use the same names that GNU programs use.
> It will be easier to remember them. For LFS profiles, we would need:
> <link>
>     <options>force</options>
> </link>
> <mkdir>
>     <options>parents</options>
> </mkdir>
> </copy>
>     <options>force archive</options>
> </copy>
> That's some minimum that LFS profiles use, we could add more latter.

Looks good to me, this way it's also possible for different implementations
to support extra options while using the same profile too, a concept close
to my heart since everytime i think i've got the FE_BE working with the new
syntax something else blows up :)

> > Links must have a type, whether this is explicitly declared or a
> default.
> > These types are also specifically defined, ie hard or symbolic. Element
> > content can be absolutely anything, not actually a problem 'cos we have
> > backend validation, user docs (ok in an ideal world :) ), but the xml
> says
> > nothing about what is allowed. In an attribute you can specify what the
> > possible values are and what the default should be. Again unless you
> are
> > validating the xml you gain nothing concrete but there is built in
> > documentation.
> I never played much with DTDs, so I didn't think about that (specifying
> possible values for attributes) at all. That seems like a good reason
> for moving it back to attribute.
> > Conversely, chroot dir can be essentially anything, and to me seems
> more
> > like a "thing" than a "property" if you see what i mean.
> > 
> > So i really like link type as an attribute, chroot dir seems more like
> an
> > element but really doesn't matter either way, so i guess if we
> shouldn't
> > get any parse errors, go for both as attribs.
> I know that you mean, but when I write "<dir>&LFS;</dir>" after <chroot>
> and
> just before some <package> in a profile, it doesn't seem natural to me at
> all.
> But as you say, it doesn't really matter in the end, so just put it where
> ever you want when you wrap up DTD.

After more thought and reading, then re-reading, I actually see no reason
dir can't be an attrib, and since it looks better there I think we should
stick with it.

> > <base> has grown on me a bit, how about <base_dir>, or <basedir> for
> easier
> > typing, bit more explicit, or does that sound too much like a pseudo
> > filesystem root ?
> I'm not very good in naming things, so I'm tempted to allow and implement
> all
> those names. ;) I'll just quietly escape from this discussion. :)
> What happened to all our profile writers?
> Don't they care about stuff like this at all?

Here here :) Lets keep <base> for now until we get a few more voices going

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

More information about the alfs-discuss mailing list