XSLT processing

Seth W.Klein sk at sethwklein.net
Wed Jan 15 13:12:27 PST 2003

Nathan Owen <owenna at engr.orst.edu> wrote:
> On Tue, Jan 14, 2003 at 05:31:16PM -0500, Seth W.Klein wrote:
> >
> > 1) I'm considering tossing some information and eliminating the
> >    description element. If you look at where i stopped with the
> >    glibc-v7 port you'll part of why and you'll also see exactly
> >    what information would be lost.
> >    Any feedback on that decision?
> Hmmm, I'm not quite sure that I see the problem here (at least so far
> as having the 'description' element). What looks unnecessarily
> complicated to me is the use of the 'description' attr with the 
> 'command' element. To me it would make more sense to include the
> description as a child of the command element like the following
> (modified from the example you gave):
> [... snipped example ...]
> Including description as a child lets me make an instant association
> between the command and the description associated with it as opposed
> to the more flattened form that it is currently in which makes use of a
> lot of idrefs. Descriptions could be added to the input/output elements
> as well, what is done with them is up to whoever writes the style-sheet.

I switched from something like your example partly to allow individual
command options to have descriptions and also because using an idref
allows authors some control over where the description appears and
simplifies stylesheets. The problem occurs when an author wants part
of the description above and part below the command. I don't know
whether to disallow that, to return to something like your example,
or to scrap the association alltogether.

> > 2) How should things like download urls be handled. I'm thinking
> >    the existing system is overkill, but then you'll probably want
> >    some form of variable for things like versions. (I don't advise
> >    their use, but others do.) Whatever system we use, it must work
> >    for both LFS and BLFS.
> >    Again, any feedback?
> I think that the link should be hard coded, as is the version number,
> and whoever updates the package to a new version updates them both. I
> don't quite get what you're asking here though (using some algorithm to
> generate the URL from a base and version number?)

I wish we could. No this is about how many places to hardcode the
information in. In other words, what is needed to avoid an undesireable
amount of duplication.

Seth W. Klein
sk at sethwklein.net                         http://www.sethwklein.net/
Maintainer, LFS FAQ             http://www.linuxfromscratch.org/faq/
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list