new dtd

Neven Has haski at sezampro.yu
Tue Nov 13 07:45:00 PST 2001


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.

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

> <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?


Neven

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



More information about the alfs-discuss mailing list