new dtd

Mark Ellis mark.uzumati at
Mon Nov 12 15:28:12 PST 2001

On 2001.11.10 19:44 Neven Has wrote:
> On Sat, Nov 10, 2001 at 12:18:03PM +0000, Mark Ellis wrote:
> > I've started to put together a dtd for the new syntax, came across a
> couple
> > of outstanding issues.
> > 
> > 1) link type, Neven where did you go with this in the end ? I've got it
> as
> > an attribute, but it makes very little difference.
> Can a link type contain '"' ? ;)

Don't even think about it :)

> But seriously, if we move "dir" from <chroot> to an element (not that I
> would
> like that), then <link> would be the only element left using attributes
> (not counting <alfs>). So we might as well get rid of all attributes?
> > 2) extra <param>'s, where do we want these, <move> <copy> and <link> ?
> Any
> > more, any less ?
> Or just keep them for <execute>, <configure>, <make> and <patch>?
> And as far as <move>, <copy>, <link> and their different options are
> concerned, how does:
> <link>
>     <options>symbolic force</options>
>     <base>&LFS;/bin</base>
>     <target>bash</target>
>     <name>sh</name>
> </link>
> sound, for example? Maybe not "options" (I'm thinking about <option>
> element
> for something else I mentioned some time ago), but something like
> that...?
> It would make adding a new options latter much nicer and easier, without
> the need for new elements/attributes (like force="yes, please" ;).

I like this a lot, it's easier to understand what the profile is saying,
from a human viewpoint not the backend's. And the backend also has a better
idea of what is happening for these specified handlers, which just seems
right. If any old command flag could be specified anywhere we might as well
have a profile of nothing but <execute>'s.

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

> > 3) chroot dir, attribute or element ? 
> Personally I prefer attribute, but is '"' allowed in a tag's attribute
> value?
> <quote from="W3C REC-xml-19980210">
> To allow attribute values to contain both single and double quotes, the
> apostrophe or single-quote character (') may be represented as "'",
> and
> the double-quote character (") as """.
> </quote>
> This should mean yes, and it makes sense, but I have no idea why some
> software doesn't parse those special entities in attribute's values (it
> parses user-defined without the problem).

Interesting, that makes sense, you should be able to have those characters
in attribs. Dunno why we're coming across parse problems then.

Anyway, my complete :) reasoning on chroot and link.

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

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.

> > 4) mount element, i just realized i'm still using this and Neven isn't,
> > probably makes more sense just to <execute> mount, any other thoughts
> > before it gets the chop ?
> We can always add it later, so I would vote to use just <execute> for
> now.


> > 5) ordering of child elements, bit more of a personal taste question
> here i
> > think. As its currently written, most elements require child elements
> in a
> > particular order. From the point of view of processing these things it
> > probably makes no difference to us whether <param> appears before
> <base> or
> > vise versa, and this can be done in the dtd. Pro's for the enforced
> order
> > way, it provides a standard of sorts and is much easier to write the
> dtd.
> > Pro's for the more lenient way, it's easier to write profiles. Does
> that
> > make sense ? Any thoughts ? Personally i like the set ordering.
> Currently, in nALFS, order doesn't matter at all, except for <param>
> elements
> which are used in the order of appearance.
> I'm not sure that I see any benefits of ordering <base>, <name>, <target>
> and similar elements within one.
> IMHO, it's just important that they are inside. :)

Me giggles manically :) OK, i'll give a non enforcing dtd a go. Have the
men in white coats ready.

> > I think that covers most of it.
> What happened to <base>?
> Should we rename it to <current_dir> or <working_dir> or something else?
> Neven

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

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