XSLT processing

Nathan Owen owenna at engr.orst.edu
Tue Jan 14 15:15:52 PST 2003


I've got some feedback as long as you're looking at it.

On Tue, Jan 14, 2003 at 05:31:16PM -0500, Seth W.Klein wrote:
> I've released lfsml 6 which contains part of
> http://linuxfromscratch.org/~gerard/new-lfs-layout/glibc-v7.html
> ported over to the new doctype.
> That porting revealed a couple issues.
> 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):

       <prompt>root at chroot:/usr/src/glibc-<dat-value package="glibc"
          type="version" name="version"/> $ </prompt>
       <prompt>root at chroot:/usr/src/glibc-<dat-value package="glibc"
          type="version" name="version"/> $ </prompt>
          It is recommended by the Glibc installation documentation
          to build Glibc outside of the source directory
          in a dedicated directory.
          Let's create such a directory
          and make it our CWD (Current Working Directory).

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.

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

Please take these with a grain of salt as I have just jumped into the
middle of the thread/monologue and have only skimmed most of the
previous posts in the thread.

Nathan Owen
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