XSLT templates to eliminate duplicated information

Hello,

it occured to me that if we have the website generated from
XML sources,
we should use this fact in a smarter way. Information which
is currently
duplicated should be kept in only one place and inserted at
the right
place in the desired output format using XSLT.

I have done a step in this direction. In the list of
developers, a person
may have <group> tags under his entry indicating to
what groups (s)he
belongs (see htdocs/People/developers.xml). Under
htdocs/People/groups, there is a list of groups with their
members.

I have created XSLT templates to autogenerate the latter
from the former
when htdocs/People/groups/index.html is recreated. This way,
it will be
necessary to update group membership in only one place. I
have also
separated the list of developers from developers.xml to a
new file,
developerlist.xml. There is also a XSLT template totext.xsl,
which creates
a textual list suitable for insertion into
src/distrib/notes/common.

I would like to commit this soon. The patch is at
http://www.
netbsd.org/~pavel/devlist.diff ,
it applies under htdocs/People.

In the future, I would like to convert the list of
portmasters to a
similar format and autogenerate the list in release notes
from it instead
of the src/distrib/notes/common/list-portmasters.pl script,
which parses
the resulting HTML. I am sure there are many other cases of
duplicated
information where a smarter approach using XSLT could help.

Pavel

Pavel Cahyna <pavelnetbsd.org> wrote:
 
> I would like to commit this soon. The patch is at
> http://www.
netbsd.org/~pavel/devlist.diff ,
> it applies under htdocs/People.

Looks just fine to me.  But then, my xsl-fu is weak to begin
with. 

> In the future, I would like to convert the list of
portmasters to a
> similar format and autogenerate the list in release
notes from it instead
> of the src/distrib/notes/common/list-portmasters.pl
script, which parses
> the resulting HTML. I am sure there are many other
cases of duplicated
> information where a smarter approach using XSLT could
help.

Yes, and I'm glad to see somebody changing this!

Thanks!
-Jan

-- 
``Life is too short to stay entirely sober.'' -- Chuck
Swiger

Pavel Cahyna <pavelNetBSD.org> wrote
  in <20070527210754.GA744beta.martani.repy.czf>:

pa> Hello,
pa>
pa> it occured to me that if we have the website
generated from XML sources,
pa> we should use this fact in a smarter way. Information
which is currently
pa> duplicated should be kept in only one place and
inserted at the right
pa> place in the desired output format using XSLT.
pa>
pa> I have done a step in this direction. In the list of
developers, a person
pa> may have <group> tags under his entry
indicating to what groups (s)he
pa> belongs (see htdocs/People/developers.xml). Under
pa> htdocs/People/groups, there is a list of groups with
their members.

 While I agree with that the direction is right, I think
putting *.xsl
 file into share/xsl is better because duplicated .xsl/.xml
files will
 be created by the translation teams.  When we use XML
database, the
 stylesheet(s) should be reusable as much as possible among
various
 languages and the language-independent part separated into
a
 language-independent directory.

pa> In the future, I would like to convert the list of
portmasters to a
pa> similar format and autogenerate the list in release
notes from it instead
pa> of the src/distrib/notes/common/list-portmasters.pl
script, which parses
pa> the resulting HTML. I am sure there are many other
cases of duplicated
pa> information where a smarter approach using XSLT could
help.

 Agreed.

--
| Hiroki SATO

On Sun, 27 May 2007, Pavel Cahyna wrote:
> I have done a step in this direction. In the list of
developers, a person
> may have <group> tags under his entry indicating
to what groups (s)he
> belongs (see htdocs/People/developers.xml). Under
> htdocs/People/groups, there is a list of groups with
their members.
>
> I have created XSLT templates to autogenerate the
latter from the former
> when htdocs/People/groups/index.html is recreated. This
way, it will be
> necessary to update group membership in only one place.
I have also
> separated the list of developers from developers.xml to
a new file,
> developerlist.xml. There is also a XSLT template
totext.xsl, which creates
> a textual list suitable for insertion into
src/distrib/notes/common.

Doesn't our "welcome" document already suggest
some file(s?) that new 
users should add themselves too (I forgot the name)? If so,
maybe we can 
make that our central "user (developer) database"
where "everything" is 
created from.

No idea what "everything" exactly is, but
investigating this a bit more 
before rushing it in may be worthwhile in the long run.

In general, I like the idea of keeping data in 1 place, and
this is 
definitely a good step!


  - Hubert

On Mon, May 28, 2007 at 07:46:23AM +0900, Hiroki Sato
wrote:
> Pavel Cahyna <pavelNetBSD.org> wrote
>   in <20070527210754.GA744beta.martani.repy.czf>:
> 
> pa> Hello,
> pa>
> pa> it occured to me that if we have the website
generated from XML sources,
> pa> we should use this fact in a smarter way.
Information which is currently
> pa> duplicated should be kept in only one place and
inserted at the right
> pa> place in the desired output format using XSLT.
> pa>
> pa> I have done a step in this direction. In the
list of developers, a person
> pa> may have <group> tags under his entry
indicating to what groups (s)he
> pa> belongs (see htdocs/People/developers.xml).
Under
> pa> htdocs/People/groups, there is a list of groups
with their members.
> 
>  While I agree with that the direction is right, I
think putting *.xsl
>  file into share/xsl is better because duplicated
.xsl/.xml files will
>  be created by the translation teams.  When we use XML
database, the
>  stylesheet(s) should be reusable as much as possible
among various
>  languages and the language-independent part separated
into a
>  language-independent directory.

I have committed this work with some modifications. There is
actually
not much XSL code. I have separated some useful
language-independent
templates and put them in share/xsl/selgrp.xsl. The file
group.xsl is
language dependent, because it creates a list of names in
English:
like Name1, Name2 and Name3. BTW I have noticed that there
are no
translations of the list of developers.

Pavel

On Mon, May 28, 2007 at 12:49:45AM +0200, Hubert Feyrer
wrote:
> On Sun, 27 May 2007, Pavel Cahyna wrote:
> >I have done a step in this direction. In the list
of developers, a person
> >may have <group> tags under his entry
indicating to what groups (s)he
> >belongs (see htdocs/People/developers.xml). Under
> >htdocs/People/groups, there is a list of groups
with their members.
> >
> >I have created XSLT templates to autogenerate the
latter from the former
> >when htdocs/People/groups/index.html is recreated.
This way, it will be
> >necessary to update group membership in only one
place. I have also
> >separated the list of developers from
developers.xml to a new file,
> >developerlist.xml. There is also a XSLT template
totext.xsl, which creates
> >a textual list suitable for insertion into
src/distrib/notes/common.
> 
> Doesn't our "welcome" document already
suggest some file(s?) that new 
> users should add themselves too (I forgot the name)? If
so, maybe we can 
> make that our central "user (developer)
database" where "everything" is 
> created from.

Yes, htdocs/People/developers.xml (and
htdocs/share/xml/developers.ent). 
This is what becomes the central developer database in my
scheme (only
with rename to htdocs/people/developerdb.xml).

> No idea what "everything" exactly is, but
investigating this a bit more 
> before rushing it in may be worthwhile in the long
run.

There is also the list in src/distrib/notes/common/main, and
I have a
XSLT script to generate it from
htdocs/people/developerdb.xml, but I
dont think it is too useful. It is not a big problem to
update those
three files after one becomes a developer, IMHO. It is more
interesting
to autogenerate lists that change more often, such as the
group
membership or list of portmasters.

Pavel