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

Loïc Péron loic.peron at bigfoot.com
Tue Apr 2 13:44:55 PST 2002

Quoting alfs-discuss at linuxfromscratch.org:
> alfs-discuss Digest	Mon, 01 Apr 2002	Volume: 03  Issue: 062


I just read all of the discussions that took place last week,
and I have some remarks:

> Date: Mon, 1 Apr 2002 22:57:19 +0100
> From: Mark Ellis <mark.uzumati at virgin.net>
> Subject: Re: Brainstorm: <stage>
> On 2002.04.01 10:11 Neven Has wrote:
> > I like the idea of creating a new environment (so there is no need
> > that
> > the user previously unsets all not needed variables). Which together
> > would give us something like:
> > 
> >     <environment mode="set|add">
> >         <variable mode="append" name="" value="" />
> >     </environment>
> > 
> > Although, I think that:
> > 
> >     <environment mode="add">
> >         <variable>
> > 		<name>HOME</name>
> > 		<value>/root</value>
> > 	</variable>
> > 
> >         <variable mode="append">
> > 		<name>PATH</name>
> > 		<value>/static/bin:/static/usr/bin</value>
> > 	</variable>
> >     </environment>
> > 
> > would be more clearer/structured/more XML-like/whatever... ?
> > 
> > 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)

> 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:
AFAIK, elements, attributes and content have different particularities:
(not including rules forced by a DTD)
. elements are first-class items, whitch are layed out in a tree with
  parent-children relations, with ordered children of any number and
  type (content or element)
. attributes are second-class items, whitch are directly dependent on
  the element they are in, are not ordered and cannot be more than one
  of a type
. content is a third-class item, contained in elements, but having no
  other XML signification than "a big chunk of text"

Thus, there are some rules that can easily and efficiently drive a choice
between a child-element and an attribute:
. how many of this item will be found under this element:
  _ if more than one, then make it a child-element
  _ else better an attribute
. is there an ordering information compared to other items:
  _ if yes, then make them child-elements
  _ else better an attribute
. is the item's content complex (more than a bare string):
  _ if yes, of course make it an element
  _ else better an element
. is the item's content a chunk of text:
  _ if yes, make it the elements's content
  _ else better an element

Now, more on with some of the rules that can be forced by a DTD:
. elements order (groups, sequenses) and number (0, 1, N, 0..1, 0..N, 1..N)
. attributes presence, default value, allowed values

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

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

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.

Loïc Péron

phone:(33) 683 880 177
mailto:loic.peron at bigfoot.com
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