emage at emage at
Mon Jun 25 20:06:09 PDT 2001

On Mon, Jun 25, 2001 at 04:03:02PM +0800, corey at wrote:
> <command id='1' name='mv' src='/bin'>
>   <opt id='1' name='-f' value=''>
>   <opt id='2' name='' value='/foo'>
>   <opt id='3' name='' value='/bar'>
> </command

I have to ask, how is that five-line example clean?  It looks like you're
adding a TON of unnecessary structure here.

I agree with Corey that we should have defined constructs for most common
tasks, like making directories, moving and installing files, etc.  That
way, if the implementation gets changed significantly, the XML code will
not.  For example, a C backend is in the works that can do many of these
tasks without the need for external programs; why burden it with the
requirement of using them?  Second, it seems like a tremendous waste of
space compared to something like:

<move src='/foo' dest='/bar' options='-f'/>

Why is that so bad?  We are defining our _own_ data setup here - any XML
conventions beyond the standards that define validity are unnecessary.

Now, I understand if you want to make some subtags for, say, all the options,
because there could be a bunch, so like this would do:

<move src='/foo' dest='/bar'>

That's an extra two lines, but still acceptible.  Here is the way I look at
things, a far as the attribute/subtag dispute:

1. If there is some information that will always be a simple string/number and
  must always be provided, it should be an attribute.
2. If something needs parsing, it should be a subtag, so that the XML parser
  will parse it for us.
3. If there are to be a variable number of things of the same type, like
  params above.
4. If there is indecision, use attributes, because they are more compact and
  easier to parse in code, since there's no nesting to worry about.
Personally, I find attributes easier to read because there's less repetition of
information...<x>stuff</x> is telling me "this is 'x'" twice, which is totally
unnecessary.  Now putting the attributes on seperate lines is great
stylistically - readability is important.

I favor using -* options like all the builtin Unix commands use because, as
 opposed to using something like <archive /> for -R in cp:
  a) they're very standard, and most of us already know them
  b) if a BE _does_ use shell commands, it can just pass them
  c) they're well-defined, so a BE implementing it's own copy/move routines
    knows exactly how to treat them.

As far as order mattering/not mattering, I agree that within a package it
shouldn't matter.  However, I see nothing wrong with using the order the
packages are listed in the profile as the order in which they're to be
installed, after a bit of processing and maybe later some dependency-checks.

I think that's most of the issues I'm concerned with.  All of this is purely
my opinion, and I'm no XML expert.  I do want to get involved, and have been
looking over the current Perl backend with an eye to keeping it up-to-date.

Soon, I'm going to run an ALFS installation so I get an image of how it goes
currently, and I'll doubtless have more ideas by then.

Walter Mundt
emage at
Unsubscribe: send email to alfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list