More metadata in LFS xml

Manuel,

I was playing around with the LFS xml, and I was trying to
figure out
a way that would be easy to export the package name and
version into
the dumped build scripts. Basically, I'm trying to write a
stylesheet
for paco right now. By adding role="install" to
the necessary screen
elements, I can easily wrap the commands for paco. I want
the output
to work like this:

paco -lp+ <package-name>-<package-version>
"
...output from userinput...
"

What I can't get right is the $name-$version part. I'm
playing with
the dump-commands.xsl stylesheet in the LFS repo since it's
simpler
than lfs.xsl in jhalfs. It seems like the place you would
want to have
this to work easily with the rest of the stylesheet is to
have them be
child elements (or attributes) of <sect1>.

<sect1>
  <package name="glibc"
version="&glibc-version;"/>
  ...
</sect1>

That, of course, doesn't work since there is no defined
package
element, and it certainly is not a child of sect1 in
docbook-xml.
Right now, it seems that you're kludging the package name
(for the
filename) from the dbhtml processing-instruction.

Is there a better way this could be done? Also, are there
any limits
to what can be placed in a processing instruction? Is there
any reason
we couldn't define our own custom pi?

<?package glibc &glibc-version;?>

Any help would be appreciated. I'm clueless on how to
"extend" the XML.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Jueves, 19 de Julio de 2007 15:34, Dan Nicholson
escribió:

> What I can't get right is the $name-$version part. I'm
playing with
> the dump-commands.xsl stylesheet in the LFS repo since
it's simpler
> than lfs.xsl in jhalfs. It seems like the place you
would want to have
> this to work easily with the rest of the stylesheet is
to have them be
> child elements (or attributes) of <sect1>.
>
> <sect1>
>   <package name="glibc"
version="&glibc-version;"/>
>   ...
> </sect1>

A "proper" syntax could be:

<sect1>
  <sect1info>
    <productname>glibc</productname>
   
<productnumber>&glibc-version;</productnumber&g
t;
  </sect1info>

But I don't like it.

> Is there a better way this could be done? Also, are
there any limits
> to what can be placed in a processing instruction? Is
there any reason
> we couldn't define our own custom pi?
>
> <?package glibc &glibc-version;?>

Creating a PI is a more elegant solution, IMHO. PIs can be
placed anywhere and 
are ignored by default by the XML/XSL processors. They are
parsed only if 
there is a stylesheet that explicity matches it.

Another beast is to create such stylesheet. If you can't do
it, I will try to 
play with this night or tomorrow.


-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On 7/19/07, M.Canales.es <macanamacana-es.com> wrote:
> El Jueves, 19 de Julio de 2007 15:34, Dan Nicholson
escribió:
>
> > What I can't get right is the $name-$version part.
I'm playing with
> > the dump-commands.xsl stylesheet in the LFS repo
since it's simpler
> > than lfs.xsl in jhalfs. It seems like the place
you would want to have
> > this to work easily with the rest of the
stylesheet is to have them be
> > child elements (or attributes) of <sect1>.
> >
> > <sect1>
> >   <package name="glibc"
version="&glibc-version;"/>
> >   ...
> > </sect1>
>
> A "proper" syntax could be:
>
> <sect1>
>   <sect1info>
>     <productname>glibc</productname>
>    
<productnumber>&glibc-version;</productnumber&g
t;
>   </sect1info>
>
> But I don't like it.

I don't mind that too much and may be necessary to solve a
different
issue below.

> > Is there a better way this could be done? Also,
are there any limits
> > to what can be placed in a processing instruction?
Is there any reason
> > we couldn't define our own custom pi?
> >
> > <?package glibc &glibc-version;?>
>
> Creating a PI is a more elegant solution, IMHO. PIs can
be placed anywhere and
> are ignored by default by the XML/XSL processors. They
are parsed only if
> there is a stylesheet that explicity matches it.

The problem is that the entities aren't resolved within the
PIs, so it
just comes out as &glibc-version;.

Another option I thought of was to use a custom DTD for
<sect1> by
just overloading the standard DocBook one with a local one.
But I'd
prefer not to do that since it adds potential for errors in
the local
sect1 definition.

> Another beast is to create such stylesheet. If you
can't do it, I will try to
> play with this night or tomorrow.

It's was actually fairly simple now that I read some of the
XSLT book
I purchased ages ago. Here's something similar I was using
when I
stuffed the name and version in the label attribute. That
was not a
good idea, but just changing the variable definitions to
parse the
processing-instruction worked, too. (Watch out for gmail
wrapping, and
ignore the $newline variable, which seems nicer than always
hardcoding
the newline entity).

--
Dan

diff --git a/BOOK/stylesheets/dump-commands.xsl
b/BOOK/stylesheets/dump-commands
index 9e2af96..e253c6d 100644
--- a/BOOK/stylesheets/dump-commands.xsl
+++ b/BOOK/stylesheets/dump-commands.xsl
 -15,6
+15,9 
   </xsl:template>

   <xsl:template match="sect1">
+      <!-- Package name and version -->
+    <xsl:variable name="package"
select="substring-before(label,' ')"/>
+    <xsl:variable name="version"
select="substring-after(label,' ')"/>
       <!-- The dirs names -->
     <xsl:variable name="pi-dir"
select="../processing-instruction('dbhtml')"/>
     <xsl:variable name="pi-dir-value"
select="substring-after($pi-dir,'dir=')"/
 -43,6
+46,16 
     </xsl:variable>
       <!-- Creating dirs and files -->
     <exsl:document
href="{$dirname}/{$order}-{$filename}"
method="text">
+      <xsl:text># build script for </xsl:text>
+      <xsl:value-of select="$package"/>
+      <xsl:value-of select="$newline"/>
+      <xsl:text>package=</xsl:text>
+      <xsl:value-of select="$package"/>
+      <xsl:value-of select="$newline"/>
+      <xsl:text>version=</xsl:text>
+      <xsl:value-of select="$version"/>
+      <xsl:value-of select="$newline"/>
+      <xsl:value-of select="$newline"/>
       <xsl:apply-templates
select=".//screen"/>
     </exsl:document>
   </xsl:template>
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On 7/19/07, Dan Nicholson <dbn.listsgmail.com> wrote:
> On 7/19/07, M.Canales.es <macanamacana-es.com> wrote:
> > El Jueves, 19 de Julio de 2007 15:34, Dan
Nicholson escribió:
> >
> > > What I can't get right is the $name-$version
part. I'm playing with
> > > the dump-commands.xsl stylesheet in the LFS
repo since it's simpler
> > > than lfs.xsl in jhalfs. It seems like the
place you would want to have
> > > this to work easily with the rest of the
stylesheet is to have them be
> > > child elements (or attributes) of
<sect1>.
> > >
> > > <sect1>
> > >   <package name="glibc"
version="&glibc-version;"/>
> > >   ...
> > > </sect1>
> >
> > A "proper" syntax could be:
> >
> > <sect1>
> >   <sect1info>
> >     <productname>glibc</productname>
> >    
<productnumber>&glibc-version;</productnumber&g
t;
> >   </sect1info>
> >
> > But I don't like it.
>
> I don't mind that too much and may be necessary to
solve a different
> issue below.

I have to say, I like this. Why don't you like using
productname and
productnumber? Does this abuse the intended purpose?

diff --git a/BOOK/chapter06/glibc.xml
b/BOOK/chapter06/glibc.xml
index 608274f..17425a2 100644
--- a/BOOK/chapter06/glibc.xml
+++ b/BOOK/chapter06/glibc.xml
 -8,6
+8,11 
 <sect1 id="ch-system-glibc"
role="wrap">
   <?dbhtml filename="glibc.html"?>

+  <sect1info>
+    <productname>glibc</productname>
+   
<productnumber>&glibc-version;</productnumber&g
t;
+  </sect1info>
+
   <title>Glibc-&glibc-version;</title>

   <indexterm zone="ch-system-glibc">
 -169,11
+174,11  grep Error
glibc-check-log</userinput></screen>
     complain about the absence of
<filename>/etc/ld.so.conf</filename>.
     Prevent this warning with:</para>

-<screen><userinput>touch
/etc/ld.so.conf</userinput></screen>
+<screen
role="install"><userinput>touch
/etc/ld.so.conf</userinput></screen>

     <para>Install the package:</para>

-<screen><userinput>make
install</userinput></screen>
+<screen
role="install"><userinput>make
install</userinput></screen>

     <para>The locales that can make the system
respond in a different language
     were not installed by the above command. None of the
locales are required,
 -214,7
+219,7  localedef -i ja_JP -f EUC-JP
ja_JP</userinput></screen>
     (it includes every locale listed above and many more)
at once with the
     following time-consuming command:</para>

-<screen><userinput>make
localedata/install-locales</userinput></screen>
+<screen
role="install"><userinput>make
localedata/install-locales</userinput></screen>

     <para>Then use the
<command>localedef</command> command to create
and
     install locales not listed in the
 -244,7
+249,7  localedef -i ja_JP -f EUC-JP
ja_JP</userinput></screen>
     <para>Create a new file
<filename>/etc/nsswitch.conf</filename> by
running
the
     following:</para>

-<screen><userinput>cat &gt;
/etc/nsswitch.conf &lt;&lt; "EOF"
+<screen role="install"><userinput>cat
&gt; /etc/nsswitch.conf &lt;&lt;
"EOF"
 <literal># Begin /etc/nsswitch.conf

 passwd: files
 -278,7
+283,7  EOF</userinput></screen>
     <para>Then create the
<filename>/etc/localtime</filename> file by
     running:</para>

-<screen><userinput>cp -v --remove-destination
/usr/share/zoneinfo/<replaceable>&lt;xxx&gt;&l
t;/replaceable> 
+<screen role="install"><userinput>cp
-v --remove-destination
/usr/share/zoneinfo/<replaceable>&lt;xxx&gt;&l
t;/replaceable> 
     /etc/localtime</userinput></screen>

     <para>Replace
<replaceable>&lt;xxx&gt;</replaceable>
with the name of the
 -326,7
+331,7  EOF</userinput></screen>
     <para>Create a new file
<filename>/etc/ld.so.conf</filename> by running
the
     following:</para>

-<screen><userinput>cat &gt; /etc/ld.so.conf
&lt;&lt; "EOF"
+<screen role="install"><userinput>cat
&gt; /etc/ld.so.conf &lt;&lt; "EOF"
 <literal># Begin /etc/ld.so.conf

 /usr/local/lib
diff --git a/BOOK/stylesheets/dump-commands.xsl
b/BOOK/stylesheets/dump-commands.xsl
index 9e2af96..039ba1d 100644
--- a/BOOK/stylesheets/dump-commands.xsl
+++ b/BOOK/stylesheets/dump-commands.xsl
 -43,14
+43,34 
     </xsl:variable>
       <!-- Creating dirs and files -->
     <exsl:document
href="{$dirname}/{$order}-{$filename}"
method="text">
+      <xsl:apply-templates
select="sect1info"/>
       <xsl:apply-templates
select=".//screen"/>
     </exsl:document>
   </xsl:template>

+  <xsl:template match="sect1info">
+    <xsl:if test="productname">
+      <xsl:text># Build script for </xsl:text>
+      <xsl:value-of select="productname"/>
+      <xsl:value-of select="$newline"/>
+      <xsl:text>package=</xsl:text>
+      <xsl:value-of select="productname"/>
+      <xsl:value-of select="$newline"/>
+    </xsl:if>
+    <xsl:if test="productnumber">
+      <xsl:text>version=</xsl:text>
+      <xsl:value-of
select="productnumber"/>
+      <xsl:value-of select="$newline"/>
+    </xsl:if>
+    <xsl:if
test="productname|productnumber">
+      <xsl:value-of select="$newline"/>
+    </xsl:if>
+  </xsl:template>
+
   <xsl:template match="screen">
     <xsl:if test="child: =
userinput">
       <xsl:choose>
-        <xsl:when test="role = 'root'">
+        <xsl:when test="role = 'root' or role =
'install'">
           <xsl:text># Run this as
root</xsl:text>
           <xsl:value-of
select="$newline"/>
           <xsl:apply-templates
select="userinput"/>
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Jueves, 19 de Julio de 2007 20:00, Dan Nicholson
escribió:

>
> The problem is that the entities aren't resolved within
the PIs, so it
> just comes out as &glibc-version;.
>

Oh, yes, that's a PITA.

> Another option I thought of was to use a custom DTD for
<sect1> by
> just overloading the standard DocBook one with a local
one. But I'd
> prefer not to do that since it adds potential for
errors in the local
> sect1 definition.

When the sources will be migrated to Relax-NG such type of
schema 
customizations will be very more easy to do.

For now, looks that the <sect1info> way is the most
semantically proper one. 
The issue is that when using DocBook-5 all <*info>
tags must be replaced by 
plain <info>.

Plus, we should to use <sect1info
condition="script"> to be sure that it's not 
rendered on the HTML or PDF outputs.



-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On 7/19/07, M.Canales.es <macanamacana-es.com> wrote:
> El Jueves, 19 de Julio de 2007 20:00, Dan Nicholson
escribió:
>
> >
> > The problem is that the entities aren't resolved
within the PIs, so it
> > just comes out as &glibc-version;.
> >
>
> Oh, yes, that's a PITA.
>
> > Another option I thought of was to use a custom
DTD for <sect1> by
> > just overloading the standard DocBook one with a
local one. But I'd
> > prefer not to do that since it adds potential for
errors in the local
> > sect1 definition.
>
> When the sources will be migrated to Relax-NG such type
of schema
> customizations will be very more easy to do.
>
> For now, looks that the <sect1info> way is the
most semantically proper one.
> The issue is that when using DocBook-5 all
<*info> tags must be replaced by
> plain <info>.

Ahh, I hadn't even considered DocBook5 yet. Good stuff to
know.

> Plus, we should to use <sect1info
condition="script"> to be sure that it's not
> rendered on the HTML or PDF outputs.

OK. Then just test for condition = 'script', right? I'll start
playing around on lfs.xsl in jhalfs since those stylesheets
are more
used than dump-commands. My goal is to resurrect the paco
functionality, but to do it in a clean way. I.e., no
patches. In my
mind, the only way to do this is at the xsl level. In the
process, I
hope to make jhalfs a little more pluggable. We'll see how
that goes.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Jueves, 19 de Julio de 2007 20:28, Dan Nicholson
escribió:

> +<screen
role="install"><userinput>touch

That don't work on BLFS and HLFS due that in that books role is
already used. 
In BLFS for role="root" and in HLFS for
role"".

Actually, I think that the unique common attibute that we
could use without 
interfering with other book's features is userlevel.

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

On 7/19/07, M.Canales.es <macanamacana-es.com> wrote:
> El Jueves, 19 de Julio de 2007 20:28, Dan Nicholson
escribió:
>
> > +<screen
role="install"><userinput>touch
>
> That don't work on BLFS and HLFS due that in that books
role
is already used.
> In BLFS for role="root" and in HLFS for
role"".

Right, that's why in the stylesheet I changed it to

<xsl:if test="role = 'root' or role = 'install'">

> Actually, I think that the unique common attibute that
we could use without
> interfering with other book's features is userlevel.

OK. I'll try using that and remove the change the test in
dump-commands.xsl.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Jueves, 19 de Julio de 2007 20:53, Dan Nicholson
escribió:

> OK. Then just test for condition = 'script',
right? I'll start
> playing around on lfs.xsl in jhalfs since those
stylesheets are more
> used than dump-commands. My goal is to resurrect the
paco
> functionality, but to do it in a clean way. I.e., no
patches. In my
> mind, the only way to do this is at the xsl level. In
the process, I
> hope to make jhalfs a little more pluggable. We'll see
how that goes.

Good )

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Jueves, 19 de Julio de 2007 20:53, Dan Nicholson
escribió:

> My goal is to resurrect the paco
> functionality, but to do it in a clean way. I.e., no
patches. In my
> mind, the only way to do this is at the xsl level. In
the process, I
> hope to make jhalfs a little more pluggable. We'll see
how that goes.

Dan, can you review the LFS/lfs.xsl code found on the
experimental branch and 
tell me if that is what you was searching for?

I'm planning a few other XML changes before start editing
the bash code to 
handle the new build scripts naming schema and content, but
the templates 
structure is ready.

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.info
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page