XML use (was: Re: Brainstorm: <stage>)

Neven Has haski at sezampro.yu
Wed Apr 3 04:33:32 PST 2002


On Tue, Apr 02, 2002 at 11:44:55PM +0200, Loïc Péron wrote:
> > > In the past we were so desperately trying to run away from the
> > > amount of attributes there were in the syntax
> 
> May I ask why? (seems I was not around at that time)

"Desperately trying to run away" sounds a bit too "strong" (bah, can't
find a word for it).

It's just that we had something like:

    <config dir="&LFS;/&build_dir;/gcc-build" 
        param1="--prefix=/usr"
        param2="--enable-languages=c,c++"
        param3="--disable-nls"
        param4="--disable-shared"
        param5="--enable-threads=posix">
            ../&gcc-directory;/configure
    </config>

for example. (Well, this is an example of something you mention below,
as a candidate for elements, not attributes, but still...).

Don't get me wrong, I don't find using attributes bad or anything.

> > I like the element structure rather than the attributes too, though in
> > this case we could probably go with either, its a "look and feel"
> > thing.
> 
> I don't think it's just a "look and feel" thing:

<snip useful guidelines>

Yes, these are the good guidelines we should use.

But still, there is also an important thing about making the profiles as
much _readable_ as we can. IMHO, that's a very important thing, and
sometimes, attributes can make that "look and feel" a bit ugly and
profiles hard to read.

But I agree we could use them a bit more where they clearly belong, as
you're stating above.

> Following those principles, most of what is actually contained in
> elements should be in attributes:
> . all path and path-like values
> . all boolean values
> . all command-line parameters
> . all short strings (package name, version, ...)

Command-line parameters probably don't belong in attributes - I think
they are the part of that "more items" category you mention.

But the others could. However, if we start using all of them as
attributes, the start tags of some elements could become quite a mess?

> I re-suggest you to have a look at ANT, and particuliarly at it's syntax:
> http://jakarta.apache.org/ant/manual/index.html sections entitled "Using
> ANT" and "Built-in tasks".

This is in my (personal) TODO for a long time (well, since you
mentioned it for the first time). I have put it on top now. :)

> I will try to write an example of how I would like to use the tasks/commands
> that have been listed at this time, but I can't guarantee anything.

Yes, more examples of different structures would be useful.


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