new dtd

Neven Has haski at sezampro.yu
Sat Nov 10 11:44:34 PST 2001

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 '"' ? ;)

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:

    <options>symbolic force</options>

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" ;).

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


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

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

> I think that covers most of it.

What happened to <base>?
Should we rename it to <current_dir> or <working_dir> or something else?


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