scrollkeeper-devel — Developer discussion list for ScrollKeeper

Re: [Scrollkeeper-devel] scrollkeeper-0.3.x and GNOME 1.4.x

[Joe M. C. <ma...@Fr...>]

On Mon, 2002-05-27 at 09:13, John Fleck wrote:
> On Sun, 2002-05-26 at 23:46, Dan Mueth wrote:
> >=20
> >=20
> > For FreeBSD, I'd recommend just using GNOME 1.4.x with the latest stabl=
e
> > ScrollKeeper (0.2.0), which should work fine.  (Note that ScrollKeeper
> > 0.3.x is the developer-only series.)  GNOME 2.0 and ScrollKeeper 0.4.0
> > should work together well and be out in a month or two.  After that, th=
e
> > use of versioned DTDs and stylesheets should allow us to maintain=20
> > backwards compatibility.
> >=20
>=20
> But there are likely to be mixed systems out there for a long time to
> come. One of the premises of GNOME2 is that a lot of old GNOME1 apps
> will not be ported in the near term, and therefore both systems should
> be able to run in parallel.
>=20
> In addition, to the extent ScrollKeeper has been adopted more widely,
> there may be other old-style OMF files remaining in the wild.
>=20
> Is it possible to make the newer versions (SK>3.6 or whenever the new
> DTD came into use) more tolerant of the error caused by an old OMF that
> doesn't validate against the DTD?

I agree.  We have users that want to test the GNOME 2 desktop, but love
Evolution and Galeon.  Obviously, we don't allow installation of the
GNOME 1.4 desktop in parallel with the GNOME 2 desktop, but I would like
to maintain one SK if possible.  Barring that, I could add a SK2 port
for SK-0.3.6, and work that into GNOME 2.  That's assuming the GNOME 1.4
libraries like it, though.

In any event, this feedback has been very useful.  I see some other
Linux distros are running into the same problem, but they are not as
picky about package list contents I guess.  I have to account for every
file installed by each package :-}.

Joe

>=20
> Cheers,
> John
> --=20
> John Fleck
> jf...@in... (h) jf...@ab... (w)
> http://www.inkstain.net http://www.abqjournal.com
>=20
> "You don't want to die with the music still in you."
>  - John Gardner
>=20
>=20

Re: [Scrollkeeper-devel] scrollkeeper-0.3.x and GNOME 1.4.x

[John F. <jf...@in...>]

On Sun, 2002-05-26 at 23:46, Dan Mueth wrote:
> 
> 
> For FreeBSD, I'd recommend just using GNOME 1.4.x with the latest stable
> ScrollKeeper (0.2.0), which should work fine.  (Note that ScrollKeeper
> 0.3.x is the developer-only series.)  GNOME 2.0 and ScrollKeeper 0.4.0
> should work together well and be out in a month or two.  After that, the
> use of versioned DTDs and stylesheets should allow us to maintain 
> backwards compatibility.
> 

But there are likely to be mixed systems out there for a long time to
come. One of the premises of GNOME2 is that a lot of old GNOME1 apps
will not be ported in the near term, and therefore both systems should
be able to run in parallel.

In addition, to the extent ScrollKeeper has been adopted more widely,
there may be other old-style OMF files remaining in the wild.

Is it possible to make the newer versions (SK>3.6 or whenever the new
DTD came into use) more tolerant of the error caused by an old OMF that
doesn't validate against the DTD?

Cheers,
John
-- 
John Fleck
jf...@in... (h) jf...@ab... (w)
http://www.inkstain.net http://www.abqjournal.com

"You don't want to die with the music still in you."
 - John Gardner

Re: [Scrollkeeper-devel] scrollkeeper-update fails misserably on Sparc

[Dan M. <mu...@al...>]

Thanks for the report and patch.  I checked it into CVS for the next 
release.

-Dan


On Thu, 23 May 2002, Christian Marillat wrote:

> Hi,
> 
> Bug report submitted by a Debian user
> 
> Christian
> 
> From: Eloy A. Paris <pe...@ch...>
> Subject: Bug#146989: libscrollkeeper0: [PATCH] scrollkeeper-update fails
> misserably on Sparc
> To: su...@bu...
> Date: Tue, 14 May 2002 17:06:56 -0400
> Reply-To: Eloy A. Paris <pe...@ch...>, 14...@bu...
> Resent-From: Eloy A. Paris <pe...@ch...>
> X-Mailer: bug 3.3.10.1
> 
> Package: libscrollkeeper0
> Version: 0.3.8-1
> Severity: important
> 
> Running scrollkeeper-update on a Sparc system was failing misserably
> with the following message:
> 
> Could not create database.  Aborting update.
> 
> Since scrollkeeper-update was being called in the postinst of several
> packages, I was unable to upgrade any of these packages (gnome-*,
> Evolution, etc.)
> 
> A little bit of investigation unconvered the problem:
> 
> cl/src/update.c:main() calls libs/database.c:create_database_directory(),
> which return 0 if succesful or 1 otherwise. cl/src/update.c:main() aborts
> if libs/database.c:create_database_directory() returns something != 0.
> 
> Unfortunately, for the case where the database directory exists, and
> is not empty, libs/database.c:create_database_directory() just returns
> without a return value. On i386 this works by lucky chance (the garbage
> happens to be 0) but on my Sparc the garbage is differnet than 0 so
> scrollkeeper-update fails to do anything, and then I can't upgrade
> my packages.
> 
> The fix is obvious:
> 
> -------------------
> diff -uNr scrollkeeper-0.3.8.orig/libs/database.c scrollkeeper-0.3.8/libs/database.c
> --- scrollkeeper-0.3.8.orig/libs/database.c	Sat Apr 20 23:14:16 2002
> +++ scrollkeeper-0.3.8/libs/database.c	Tue May 14 16:48:45 2002
> @@ -122,7 +122,7 @@
>      closedir(dir);
>      
>      if (!empty)
> -        return;
> +        return 0;
>          
>      data_dir = malloc((strlen(scrollkeeper_data_dir)+strlen("/Templates")+1)*
>      			sizeof(char));
> -------------------
> 
> Cheers,
> 
> Eloy.-
> pe...@de...
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
> 

Re: [Scrollkeeper-devel] strange DTD changes

[Dan M. <mu...@al...>]

Thanks for the discussion. It is nice to read it and preserve it here.  
Thanks also for volunteering to work on the DTD.  I'm sure you and Eric
can come up with a great new version.  I think in general the OMF has been
languishing a bit, and the discrepencies between the spec and DTD are
annoying.  It would be good to close up the gaps.

Could anybody comment on the viability of writing a stylesheet to convert 
OMF files from one DTD version to another?  It seems completely doable, 
and I think John has already done this for migrating OMF files from SK-0.2 
to SK-0.3.x/0.4, although I'm not sure what the final verdict is on how 
well it works.  Comments John?

I think we generally want to get any nasty bugs remaining in 0.3.x fixed 
and put out 0.4.0 soon.  Then we can start working on some of these 
problems in the 0.5.x developer series.  So far I think the big changes 
for 0.5.x/0.6.0 are:

1) DTD cleanup (and stylesheet/code for backward compatibility of OMFs)
2) URI resolution (eg. for cross-referencing documents)

Anything else?

Technically these should be straightforward, but they both require a fair
amount of thought so we come up with a sane standard.

Dan


On Sat, 25 May 2002, Martijn van Beers wrote:

> On Mon, May 20, 2002 at 12:01:20AM -0500, Dan Mueth wrote:
> > I'm open to arguments for why we should or should not use the <person> 
> > tag in place of RFC822.
> 
> 
> So, I happened on Eric Baudais on irc the other day, and we had the
> following enlightening discussion:
> 
> [...]
>  * LotR thwaps drake for writing such a lousy one
> <drake> I was just doing as I was told to anyways.  I think SK should
>         use V2 of OMF anyways.
> <drake> I wrote the DTD for that one with an emphasis on
>         compliance with V1.0 of the OMF.
> <LotR> there's a newer version of the OMF spec then?
> <drake> Yes, it does things The Right Way (tm).  It's either 1.2
>         of 2.0...cannot remember which now.  SK uses the older OMF spec.
> <LotR> url?
> <LotR> (the website only seems to have 1.0)
> <drake> Look at the DTD at
>         http://ibiblio.org/pub/Linux/metadata/OMF.dtd
> <LotR> oh, that's newer?
> <drake> Also take a look at
>         http://dulug.duke.edu/~mark/docs/dtds/xml/omf-1.1/index.html
> <LotR> now I'm really confused
> <LotR> was there also a 1.0 DTD?
> <drake> Yes, that is the one I modified and SK uses.
> <LotR> but earlier OMF files already used the <person> bits from
>        more recent DTDs
> <drake> What SK was using prior was a format halfway between OMF
>         1.0 and OMF 1.1.  I do not think that OMF 1.0 defined <person>.
> <LotR> oh
> <LotR> so why was the decision made to use V1.0?
> <LotR> and if you think we should use a newer version, could you
>        weigh in on the current thread I started?
> <drake> I don't think there was a decision, but SK had always been
>         using V1.0.
> <drake> Okay, I think that Dan told me that V1.0 of OMF never had
>         a DTD, but V1.1 of OMF did.
> <drake> I looked at the V1.1 DTD and saw there were serious
>         changes between the published documentation from OMF and the DTD.
> <drake> Example: There is a toplevel element <versionGroup> which
>         has a child of <version>.  <version> has children <id>, <date>,
>         and <description>.
> <LotR> yeah, the newer ones are much better xml
> <drake> This contradicts what the OMF element description says,
>         which is that there is one element <version> with three
>         attributes, version.identifier, version.date, and
>         version.description.
> <drake> Since Dan had been using and relying on the V1.0
>         documentation, I just reconstructed what the DTD would be like
>         if one was written for V1.0.  Then I modified it for SK's
>         specific uses.
> <LotR> the OMF people are obviously not very good at version
>        management :)
> <drake> Yes, it's rather a mess.
> <drake> That is the basic history and a lot of my thoughts on how
>         I wrote the DTD which is now in SK.
> <drake> Now that we have something defined, I think people can
>         make cases on whether the DTD is good for SK or if it should be
>         modified and updated.
> [...]
> 
> So, it seems the spec was for version 1.0 of the DTD (which doesn't seem
> to have ever existed), and old scrollkeeper versions seem to have used
> some version of the 1.1 version of the DTD. Hopefully we can change back
> to basing the scrollkeeper DTD on the latest OMF DTD, which is much more
> sane ASAP after the gnome 2.0 release. I'll try to create a DTD based on
> it, with the extra information scrollkeeper wants, like the <relation> tag,
> and send it to the list for discussion.
> 
> 
> Martijn
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
> 

Re: [Scrollkeeper-devel] scrollkeeper-0.3.x and GNOME 1.4.x

[Dan M. <mu...@al...>]

On 27 May 2002, Joe Marcus Clarke wrote:

> Hi, I'm with the FreeBSD GNOME porting team, and I recently ran into a
> big problem when I upgraded scrollkeeper from 0.2 to 0.3.6 on FreeBSD. 
> Some of the OMF files included with gnome-core (and I'm sure other GNOME
> 1.4 ports might have been affected as well) failed to compile under
> scrollkeeper-preinstall because they contained illegal UTF-8 characters.
> 
> I realize this is due to the fact that scrollkeeper-0.3.x uses libxml2
> which requires all XML to be in UTF-8 or -16 or have an encoding
> directive in the <?xml ?> header.  I know this issue probably falls
> squarely in the GNOME camp, but I thought I'd test the waters here, too.
> 
> Is there a way to get scrollkeeper 0.3.x to play nicely with GNOME 1.4.x
> without going through and patching all the OMF files to have an
> encoding="ISO-8859-1" directive?

As things stand now, there is no simple way to get Sk-0.3.x to work nicely
with GNOME 1.4.x without editing lots of OMF files and docs.  The major
change was that we moved from libxml to libxml2, while the docs moved from
DocBook/SGML to DocBook/XML.  As you have noted, the encoding must be
explicitly stated for many locales.  Additionally, Sk >= 0.3.6 validates
the OMF files before trying to use them, and the GNOME 1.4.x OMF files
won't validate without a couple changes.  There is little value in getting
SK-0.3.x to work with GNOME-1.4.x since it works for DocBook/XML, but not
DocBook/SGML which is what is in GNOME-1.4.x.

It is unfortunate that this compatibility had to be broken, but it was
better to get all these improvements(SGML->XML, libxml->libxml2, no
DTD->DTD validation) in early on.  In the future, any changes to the DTD
can be more cleanly handled since we can use multiple DTD versions, and
write stylesheets to convert between them automatically.  I don't forsee 
any changes in the preferred document format or xml libraries for a long 
time.

For FreeBSD, I'd recommend just using GNOME 1.4.x with the latest stable
ScrollKeeper (0.2.0), which should work fine.  (Note that ScrollKeeper
0.3.x is the developer-only series.)  GNOME 2.0 and ScrollKeeper 0.4.0
should work together well and be out in a month or two.  After that, the
use of versioned DTDs and stylesheets should allow us to maintain 
backwards compatibility.

Dan

[Scrollkeeper-devel] scrollkeeper-0.3.x and GNOME 1.4.x

[Joe M. C. <ma...@Fr...>]

Hi, I'm with the FreeBSD GNOME porting team, and I recently ran into a
big problem when I upgraded scrollkeeper from 0.2 to 0.3.6 on FreeBSD. 
Some of the OMF files included with gnome-core (and I'm sure other GNOME
1.4 ports might have been affected as well) failed to compile under
scrollkeeper-preinstall because they contained illegal UTF-8 characters.

I realize this is due to the fact that scrollkeeper-0.3.x uses libxml2
which requires all XML to be in UTF-8 or -16 or have an encoding
directive in the <?xml ?> header.  I know this issue probably falls
squarely in the GNOME camp, but I thought I'd test the waters here, too.

Is there a way to get scrollkeeper 0.3.x to play nicely with GNOME 1.4.x
without going through and patching all the OMF files to have an
encoding="ISO-8859-1" directive?

Sorry if this has been asked before.  I couldn't find a good search of
the scrollkeeper-devel archives.  I'd be happy to receive any points or
other documentation to read.  I've through the Encoding section of the
libxml pages, but I didn't see anything other than adding the encoding
directive.  Thanks.

Joe

Re: [Scrollkeeper-devel] strange DTD changes

[Martijn v. B. <ma...@ee...>]

On Mon, May 20, 2002 at 12:01:20AM -0500, Dan Mueth wrote:
> I'm open to arguments for why we should or should not use the <person> 
> tag in place of RFC822.


So, I happened on Eric Baudais on irc the other day, and we had the
following enlightening discussion:

[...]
 * LotR thwaps drake for writing such a lousy one
<drake> I was just doing as I was told to anyways.  I think SK should
        use V2 of OMF anyways.
<drake> I wrote the DTD for that one with an emphasis on
        compliance with V1.0 of the OMF.
<LotR> there's a newer version of the OMF spec then?
<drake> Yes, it does things The Right Way (tm).  It's either 1.2
        of 2.0...cannot remember which now.  SK uses the older OMF spec.
<LotR> url?
<LotR> (the website only seems to have 1.0)
<drake> Look at the DTD at
        http://ibiblio.org/pub/Linux/metadata/OMF.dtd
<LotR> oh, that's newer?
<drake> Also take a look at
        http://dulug.duke.edu/~mark/docs/dtds/xml/omf-1.1/index.html
<LotR> now I'm really confused
<LotR> was there also a 1.0 DTD?
<drake> Yes, that is the one I modified and SK uses.
<LotR> but earlier OMF files already used the <person> bits from
       more recent DTDs
<drake> What SK was using prior was a format halfway between OMF
        1.0 and OMF 1.1.  I do not think that OMF 1.0 defined <person>.
<LotR> oh
<LotR> so why was the decision made to use V1.0?
<LotR> and if you think we should use a newer version, could you
       weigh in on the current thread I started?
<drake> I don't think there was a decision, but SK had always been
        using V1.0.
<drake> Okay, I think that Dan told me that V1.0 of OMF never had
        a DTD, but V1.1 of OMF did.
<drake> I looked at the V1.1 DTD and saw there were serious
        changes between the published documentation from OMF and the DTD.
<drake> Example: There is a toplevel element <versionGroup> which
        has a child of <version>.  <version> has children <id>, <date>,
        and <description>.
<LotR> yeah, the newer ones are much better xml
<drake> This contradicts what the OMF element description says,
        which is that there is one element <version> with three
        attributes, version.identifier, version.date, and
        version.description.
<drake> Since Dan had been using and relying on the V1.0
        documentation, I just reconstructed what the DTD would be like
        if one was written for V1.0.  Then I modified it for SK's
        specific uses.
<LotR> the OMF people are obviously not very good at version
       management :)
<drake> Yes, it's rather a mess.
<drake> That is the basic history and a lot of my thoughts on how
        I wrote the DTD which is now in SK.
<drake> Now that we have something defined, I think people can
        make cases on whether the DTD is good for SK or if it should be
        modified and updated.
[...]

So, it seems the spec was for version 1.0 of the DTD (which doesn't seem
to have ever existed), and old scrollkeeper versions seem to have used
some version of the 1.1 version of the DTD. Hopefully we can change back
to basing the scrollkeeper DTD on the latest OMF DTD, which is much more
sane ASAP after the gnome 2.0 release. I'll try to create a DTD based on
it, with the extra information scrollkeeper wants, like the <relation> tag,
and send it to the list for discussion.


Martijn

[Scrollkeeper-devel] Library should be linked against libxslt

[Christian M. <mar...@fr...>]

Hi,

libs/extract.c call some xslt functions

Christian

--- libs/Makefile.am.orig       Thu May 23 18:42:49 2002
+++ libs/Makefile.am    Thu May 23 18:43:08 2002
@@ -17,4 +17,4 @@
        uninstall.c \
        update-url.c
 
-libscrollkeeper_la_LIBADD = $(XML_LIBS)
+libscrollkeeper_la_LIBADD = $(XML_LIBS) $(XSLT_LIBS)

[Scrollkeeper-devel] install() function don't skip comment nodes while looking for <OMF>

[Christian M. <mar...@fr...>]

Hi,

Another patche from a Debian user

Christian

From: "J.H.M. Dassen (Ray)" <dm...@ze...>
Subject: Bug#146848: Patch
To: 14...@bu...
Date: Wed, 22 May 2002 22:26:24 +0200
User-Agent: Mutt/1.3.28i
Reply-To: "J.H.M. Dassen (Ray)" <dm...@ze...>, 14...@bu...
Resent-From: "J.H.M. Dassen (Ray)" <dm...@ze...>

This makes the install() function skip comment nodes while looking for <OMF>
elements.

It may well be that there are other places where (lib)scrollkeeper's code
needs refinement to deal with comment nodes the right way. Also, the
install() function really should be rewritten to not have code paths along
which it fails without providing a clue for debugging.

diff -r -u scrollkeeper-0.3.8/libs/install.c scrollkeeper-devel/libs/install.c
--- scrollkeeper-0.3.8/libs/install.c	Sun Apr 21 05:14:16 2002
+++ scrollkeeper-devel/libs/install.c	Wed May 22 22:14:28 2002
@@ -144,11 +144,14 @@
     return toc_tree;
 }
 
+/* FIXME: this function should be rewritten to provide warnings/errors for all
+   cases in which it doesn't install an OMF entry. Currently it may fail
+   silently for a variety of reasons. */
 int install(char *omf_name, char *scrollkeeper_dir, char *data_dir, char
outputprefs)
 {    
     xmlDocPtr omf_doc;
     xmlDtdPtr dtd;
-    xmlNodePtr node, s_node;
+    xmlNodePtr node, omf_node, s_node;
     char *docpath, *title, *format, str[1024];
     char cl_filename[PATHLEN], cl_ext_filename[PATHLEN];
     char locale_dir[PATHLEN], locale_name[PATHLEN], *locale, *ptr;
@@ -193,7 +196,24 @@
        they should start from the top node's children
     */
 
-    for(node = omf_doc->children->children; node != NULL; node = node->next)
+    /* Well, sort of. Let's do the right thing when comments are involved. */
+    for(omf_node = omf_doc->children;
+
(omf_node != NULL) && (omf_node->type != XML_ELEMENT_NODE);
+
omf_node = omf_node->next)
+
;;
+
+    if (!omf_node) {
+
/* This should not happen */
+
sk_message(outputprefs, SKOUT_DEFAULT, SKOUT_QUIET, "(install)", _("Failed to
locate an <OMF> element.\n"));
+
return 0;
+    }
+    if (!omf_node->children) {
+
/* This should not happen */
+
sk_message(outputprefs, SKOUT_DEFAULT, SKOUT_QUIET, "(install)", _("<OMF> node
has no children.\n"));
+
return 0;
+    }
+
+    for(node = omf_node->children; node != NULL; node = node->next)
     {
         if (!xmlStrcmp(node->name, (xmlChar *)"resource"))
 	{
-- 

[Scrollkeeper-devel] scrollkeeper-update fails misserably on Sparc

[Christian M. <mar...@fr...>]

Hi,

Bug report submitted by a Debian user

Christian

From: Eloy A. Paris <pe...@ch...>
Subject: Bug#146989: libscrollkeeper0: [PATCH] scrollkeeper-update fails
misserably on Sparc
To: su...@bu...
Date: Tue, 14 May 2002 17:06:56 -0400
Reply-To: Eloy A. Paris <pe...@ch...>, 14...@bu...
Resent-From: Eloy A. Paris <pe...@ch...>
X-Mailer: bug 3.3.10.1

Package: libscrollkeeper0
Version: 0.3.8-1
Severity: important

Running scrollkeeper-update on a Sparc system was failing misserably
with the following message:

Could not create database.  Aborting update.

Since scrollkeeper-update was being called in the postinst of several
packages, I was unable to upgrade any of these packages (gnome-*,
Evolution, etc.)

A little bit of investigation unconvered the problem:

cl/src/update.c:main() calls libs/database.c:create_database_directory(),
which return 0 if succesful or 1 otherwise. cl/src/update.c:main() aborts
if libs/database.c:create_database_directory() returns something != 0.

Unfortunately, for the case where the database directory exists, and
is not empty, libs/database.c:create_database_directory() just returns
without a return value. On i386 this works by lucky chance (the garbage
happens to be 0) but on my Sparc the garbage is differnet than 0 so
scrollkeeper-update fails to do anything, and then I can't upgrade
my packages.

The fix is obvious:

-------------------
diff -uNr scrollkeeper-0.3.8.orig/libs/database.c scrollkeeper-0.3.8/libs/database.c
--- scrollkeeper-0.3.8.orig/libs/database.c	Sat Apr 20 23:14:16 2002
+++ scrollkeeper-0.3.8/libs/database.c	Tue May 14 16:48:45 2002
@@ -122,7 +122,7 @@
     closedir(dir);
     
     if (!empty)
-        return;
+        return 0;
         
     data_dir = malloc((strlen(scrollkeeper_data_dir)+strlen("/Templates")+1)*
     			sizeof(char));
-------------------

Cheers,

Eloy.-
pe...@de...

[Scrollkeeper-devel] Re: scrollkeepr problems

[Chris L. <ch...@wi...>]

Thanks, Dan

This was the trick I needed, changing the path in scrollkeeper.conf to
/gnome/head/INSTALL/share/omf and running scrollkeeper-rebuilddb
registered all the docs properly, now I can get down to fixing all the
rest of the OMF files this weekend.

Chris

On Tue, 2002-05-21 at 21:03, Dan Mueth wrote:
> 
> Hi Chris,
> 
> My guess is that your valid OMF files are in a path that isn't listed in 
> /etc/scrollkeeper.conf, while your invalid OMF files are in the paths in 
> /etc/scrollkeeper.conf.  Try editing the list of paths in 
> /etc/scrollkeeper.conf to include the paths for your GNOME2 installation, 
> and then run 'scrollkeeper-rebuilddb'.
> 
> Note that 'scrollkeeper-rebuilddb' and 'scrollkeeper-update' will 
> generally search the paths in the conf file, and not the working 
> directory.  You can change this with command-line flags however.
> 
> Also, the paths listed in scrollkeeper.conf can be determined at build 
> time.  If you are using Garnome, for example, you might want to make sure 
> it is setting these paths to be appropriate for its install directory.
> 
> Dan
> 
> 
> On 20 May 2002, Chris Lyttle wrote:
> 
> > Well I finally managed to make sure my xml stuff was setup correctly,
> > fired up the nice new yelp from cvs only to discover it listed no docs
> > apart from 'Writing scrollkeeper omf files' and man and info pages.
> > Curious as to why this should be I thought that possibly SK needed to
> > update it's db and couldn't because it was owned by root.
> > So I went into the build directory (for gnome-games which is what I've
> > been trying to get working) and ran scrollkeeper-update which I
> > understood would scan all the directories below this for omf files to
> > install.It came back with a bunch of error's basically saying that the
> > OMF files weren't valid  I was pretty sure they were as I'd followed the
> > guidelines on the SK site to set them up, but I used xmllint to check
> > them anyway against the sk dtd. there were no errors. I poked around for
> > a bit more then came across the scrollkeeper-install test on the SK
> > site. I tried this and it worked perfectly. So I tried running
> > scrollkeeper-install as root to install the files, they worked and this
> > doc now shows up in Yelp properly.
> > I think all this means that the command we are using in omf.make
> > (scrollkeeper-update) doesn't work and this is why docs aren't getting
> > registered.
> > 
> > Comments?
> > Chris
> > 
> > 
> > 
> > _______________________________________________
> > gnome-doc-list mailing list
> > gno...@gn...
> > http://mail.gnome.org/mailman/listinfo/gnome-doc-list
> > 

[Scrollkeeper-devel] Re: scrollkeepr problems

[Dan M. <mu...@al...>]

Hi Chris,

My guess is that your valid OMF files are in a path that isn't listed in 
/etc/scrollkeeper.conf, while your invalid OMF files are in the paths in 
/etc/scrollkeeper.conf.  Try editing the list of paths in 
/etc/scrollkeeper.conf to include the paths for your GNOME2 installation, 
and then run 'scrollkeeper-rebuilddb'.

Note that 'scrollkeeper-rebuilddb' and 'scrollkeeper-update' will 
generally search the paths in the conf file, and not the working 
directory.  You can change this with command-line flags however.

Also, the paths listed in scrollkeeper.conf can be determined at build 
time.  If you are using Garnome, for example, you might want to make sure 
it is setting these paths to be appropriate for its install directory.

Dan


On 20 May 2002, Chris Lyttle wrote:

> Well I finally managed to make sure my xml stuff was setup correctly,
> fired up the nice new yelp from cvs only to discover it listed no docs
> apart from 'Writing scrollkeeper omf files' and man and info pages.
> Curious as to why this should be I thought that possibly SK needed to
> update it's db and couldn't because it was owned by root.
> So I went into the build directory (for gnome-games which is what I've
> been trying to get working) and ran scrollkeeper-update which I
> understood would scan all the directories below this for omf files to
> install.It came back with a bunch of error's basically saying that the
> OMF files weren't valid  I was pretty sure they were as I'd followed the
> guidelines on the SK site to set them up, but I used xmllint to check
> them anyway against the sk dtd. there were no errors. I poked around for
> a bit more then came across the scrollkeeper-install test on the SK
> site. I tried this and it worked perfectly. So I tried running
> scrollkeeper-install as root to install the files, they worked and this
> doc now shows up in Yelp properly.
> I think all this means that the command we are using in omf.make
> (scrollkeeper-update) doesn't work and this is why docs aren't getting
> registered.
> 
> Comments?
> Chris
> 
> 
> 
> _______________________________________________
> gnome-doc-list mailing list
> gno...@gn...
> http://mail.gnome.org/mailman/listinfo/gnome-doc-list
> 

Re: [Scrollkeeper-devel] strange DTD changes

[David M. <da...@lu...>]

On Mon, May 20, 2002 at 12:08:21PM +0200, Martijn van Beers wrote:
> On Mon, May 20, 2002 at 12:01:20AM -0500, Dan Mueth wrote:
> > 
> > Hi Martijn,
> > 
> > I had a similar reluctance to doing away with the beauty and convention of
> > XML and <person>.  The reason why we are currently recommending the form
> > "lo...@us... (Martijn van Beers)" is because that is what
> > is specified by the OMF spec for <creator>.  To quote the spec:
> 
> Hrm, very strange. According to their DTD
> (http://www.ibiblio.org/pub/Linux/metadata/OMF.dtd) you do
> use <person>. Also, their OMF generation CGI also uses the <person>
> 
> ... After reading some of the omf list archives (and I thought other
> web interfaces to mailing lists were horrid!) ...
> 
> It seems like you guys have assumed the 'spec' to be authorative,
> while they seem to be saying ask. 
> 
> > I'm open to arguments for why we should or should not use the <person> 
> > tag in place of RFC822.
> 
> * XML is a markup language. you mark up things humans understand
>   already, so an application can easily make sense of them too.
>   rfc822 format is not an example of this

I very much agree with this. I think going rfc822 was a mistake, and
would like to see it back the way it was. Keep the XML, well, XML.

-- 
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Lead Developer                                 http://www.tldp.org

The heart may freeze or it can burn
The pain will ease if I can learn
There is no future
There is no past
I live this moment as my last
There's only us
There's only this
Forget regret
Or life is yours to miss
No other road
No other way
No day but today
	-- RENT

Re: [Scrollkeeper-devel] strange DTD changes

[Martijn v. B. <ma...@ee...>]

On Tue, May 21, 2002 at 12:38:01PM -0500, Dan Mueth wrote:
> Well, the spec should be the reference, not any particular implementation 
> of the spec.

From what I've seen on the mailing-list neither the spec nor any
implementation was set in stone.

> In the case of <person>, the conversion from <person> to RFC822 is simple.  
> The reverse is not always possible, which is unfortunate.  It would be
> nice if you could convert an OMF database from one format to another
> without problems or loss.

But *why* would you want to do that? If you think of the spec as the
final word on the syntax, then you cannot have <person> & friends. And
if you have <person>, you really have no use for a dumbed down
representation of the data.


(maybe we should try to get the original OMF people involved into this)


Martijn

Re: [Scrollkeeper-devel] strange DTD changes

[Dan M. <mu...@al...>]

On Tue, 21 May 2002, Martijn van Beers wrote:

> On Mon, May 20, 2002 at 11:59:38PM -0700, Gregory Leblanc wrote:
> > 
> > Yeah, but the DTD doesn't necessarily reflect the spec, nor does the
> > CGI.  I tried to get this straightened up, but I didn't have much luck. 
> > I've since stopped trying, I don't have the time to work on it to the
> > extent that's required.  
> 
> But why pick the worst of the three as your reference??

Well, the spec should be the reference, not any particular implementation 
of the spec.

Having said that, one may argue that as long as one can create an OMF DTD
and an accompanying XSLT stylesheet that outputs the email addresses in
RFC822 format, then it doesn't really matter what the internal structure
of the email address is in the XML file.  

I think the spec is for the information, and not the way it is stored, so
I think you can create an arbitrary binary data format so long as you have
a way to decode it into the form which follows the OMF spec.

In the case of <person>, the conversion from <person> to RFC822 is simple.  
The reverse is not always possible, which is unfortunate.  It would be
nice if you could convert an OMF database from one format to another
without problems or loss.  By enriching the <creator>, we may lose this
flexibility.  It sounds like we may want to support both RFC822 (in the
tag body) and <person> (as a child) for <creator>.  This would allow an 
XML OMF file to be converted to format B and then back, and still have 
valid OMF data (although the richness of <person> would be lost in the 
process).

What do you think about this approach?

Dan

Re: [Scrollkeeper-devel] strange DTD changes

[Martijn v. B. <ma...@ee...>]

On Mon, May 20, 2002 at 11:59:38PM -0700, Gregory Leblanc wrote:
> 
> Yeah, but the DTD doesn't necessarily reflect the spec, nor does the
> CGI.  I tried to get this straightened up, but I didn't have much luck. 
> I've since stopped trying, I don't have the time to work on it to the
> extent that's required.  

But why pick the worst of the three as your reference??


Martijn

Re: [Scrollkeeper-devel] strange DTD changes

[Gregory L. <gle...@li...>]

On Mon, 2002-05-20 at 03:08, Martijn van Beers wrote:
> On Mon, May 20, 2002 at 12:01:20AM -0500, Dan Mueth wrote:
> > 
> > Hi Martijn,
> > 
> > I had a similar reluctance to doing away with the beauty and convention of
> > XML and <person>.  The reason why we are currently recommending the form
> > "lo...@us... (Martijn van Beers)" is because that is what
> > is specified by the OMF spec for <creator>.  To quote the spec:
> 
> Hrm, very strange. According to their DTD
> (http://www.ibiblio.org/pub/Linux/metadata/OMF.dtd) you do
> use <person>. Also, their OMF generation CGI also uses the <person>

Yeah, but the DTD doesn't necessarily reflect the spec, nor does the
CGI.  I tried to get this straightened up, but I didn't have much luck. 
I've since stopped trying, I don't have the time to work on it to the
extent that's required.  
	Greg

-- 
Portland, Oregon, USA.
Please don't copy me on replies to the list.

[Scrollkeeper-devel] scrollkeepr problems

[Chris L. <ch...@wi...>]

Well I finally managed to make sure my xml stuff was setup correctly,
fired up the nice new yelp from cvs only to discover it listed no docs
apart from 'Writing scrollkeeper omf files' and man and info pages.
Curious as to why this should be I thought that possibly SK needed to
update it's db and couldn't because it was owned by root.
So I went into the build directory (for gnome-games which is what I've
been trying to get working) and ran scrollkeeper-update which I
understood would scan all the directories below this for omf files to
install.It came back with a bunch of error's basically saying that the
OMF files weren't valid  I was pretty sure they were as I'd followed the
guidelines on the SK site to set them up, but I used xmllint to check
them anyway against the sk dtd. there were no errors. I poked around for
a bit more then came across the scrollkeeper-install test on the SK
site. I tried this and it worked perfectly. So I tried running
scrollkeeper-install as root to install the files, they worked and this
doc now shows up in Yelp properly.
I think all this means that the command we are using in omf.make
(scrollkeeper-update) doesn't work and this is why docs aren't getting
registered.

Comments?
Chris

Re: [Scrollkeeper-devel] strange DTD changes

[Martijn v. B. <ma...@ee...>]

On Mon, May 20, 2002 at 12:01:20AM -0500, Dan Mueth wrote:
> 
> Hi Martijn,
> 
> I had a similar reluctance to doing away with the beauty and convention of
> XML and <person>.  The reason why we are currently recommending the form
> "lo...@us... (Martijn van Beers)" is because that is what
> is specified by the OMF spec for <creator>.  To quote the spec:

Hrm, very strange. According to their DTD
(http://www.ibiblio.org/pub/Linux/metadata/OMF.dtd) you do
use <person>. Also, their OMF generation CGI also uses the <person>

... After reading some of the omf list archives (and I thought other
web interfaces to mailing lists were horrid!) ...

It seems like you guys have assumed the 'spec' to be authorative,
while they seem to be saying ask. 

> I'm open to arguments for why we should or should not use the <person> 
> tag in place of RFC822.

* XML is a markup language. you mark up things humans understand
  already, so an application can easily make sense of them too.
  rfc822 format is not an example of this
* the original matches much better with DocBook's author/etc tags

While we're discussing changes, why was category changed into an
attribute
<subject category="foo" />

instead of
<subject>foo</subject>

I really don't see any advantages of this. (and why does gnome need it's
own category anyway?)

I do like the new syntax for <format>, but it may be a good idea to
add an optional attribute to specify an url where to fetch the DTD

Another thing I don't like in the changed DTD is how rights turned
into one element with just attributes
<rights>
	<license name="FDL" version="1.1" url="foo" />
	<holder>joe shmoe</holder>
</rights>

makes much more sense than the way it is now.
Another regression from the original DTD is the <version> tag. putting
things like a description into an attribute really doesn't make much
sense.

(http://lists.xml.org/archives/xml-dev/200205/msg01027.html for a good
thread on element vs. attribute)


Martijn

Re: [Scrollkeeper-devel] strange DTD changes

[Dan M. <mu...@al...>]

Hi Martijn,

I had a similar reluctance to doing away with the beauty and convention o=
f
XML and <person>.  The reason why we are currently recommending the form
"lo...@us... (Martijn van Beers)" is because that is what
is specified by the OMF spec for <creator>.  To quote the spec:

---
1.      Author or Creator
        Label: CREATOR
        Obligation: Mandatory
        Maximum Occurrence : Repeatable
The person or organization primarily responsible for creating the
intellectual content of the resource. CREATOR should appear in RFC822
format (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt).
Preferred format: mai...@si... (Full Name)
---

I'm open to arguments for why we should or should not use the <person>=20
tag in place of RFC822.   If we get a concencus, this would be the best=20
time to make updates, but in such a way that it doesn't break OMF files=20
that were written lately.

Dan



On Thu, 17 May 2001, Martijn van Beers wrote:

> Hi,
>=20
> I was updating my db2omf.xsl stylesheet, (the old version is at
> gnome-docu/gdp/tools/db2omf.xsl if anyone wants to add it to
> the 'other resources' section of the omf file manual) when I
> noticed that the current DTD doesn't really deserve the
> term 'scrollkeeper OMF variant', since it isn't a variant, but
> a completely different beast.
>=20
> The initial check-in changelog entry says:
>=20
>         * extract/dtds/scrollkeeper-omf.dtd: Adding this file from=20
> 	  Eric Baudais <ba...@ok...>.  It is the OMF DTD
> 	  with a few ScrollKeeper-specific variations.
>  	  Eventually we will feed these upstream.
>=20
> But these are hardly 'a few variations'
>=20
> instead of:
>=20
> <creator>
> 	<person>
> 		<firstName>Martijn</firstName>
> 		<lastName>van Beers</lastName>
> 		<email>lo...@us...</email>
> 	</person>
> </creator>
>=20
> according to the docs, one now has to do:
> <creator>
> 	lo...@us... (Martijn van Beers)
> </creator>
>=20
> which begs the question why use xml at all anymore when you really seem
> to be wanting to parse all the relevant information out of a simple
> string anyway.
>=20
> I've looked through the scrollkeeper-devel and gnome-doc-list archives,
> but I haven't been able to find any discussion that might explain these
> very odd changes. Please enlighten me,
>=20
>=20
> Martijn
>=20
>=20
> _______________________________________________________________
>=20
> Hundreds of nodes, one monster rendering program.
> Now that=92s a super model! Visit http://clustering.foundries.sf.net/
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> https://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
>=20

[Scrollkeeper-devel] strange DTD changes

[Martijn v. B. <ma...@ee...>]

Hi,

I was updating my db2omf.xsl stylesheet, (the old version is at
gnome-docu/gdp/tools/db2omf.xsl if anyone wants to add it to
the 'other resources' section of the omf file manual) when I
noticed that the current DTD doesn't really deserve the
term 'scrollkeeper OMF variant', since it isn't a variant, but
a completely different beast.

The initial check-in changelog entry says:

        * extract/dtds/scrollkeeper-omf.dtd: Adding this file from 
	  Eric Baudais <ba...@ok...>.  It is the OMF DTD
	  with a few ScrollKeeper-specific variations.
 	  Eventually we will feed these upstream.

But these are hardly 'a few variations'

instead of:

<creator>
	<person>
		<firstName>Martijn</firstName>
		<lastName>van Beers</lastName>
		<email>lo...@us...</email>
	</person>
</creator>

according to the docs, one now has to do:
<creator>
	lo...@us... (Martijn van Beers)
</creator>

which begs the question why use xml at all anymore when you really seem
to be wanting to parse all the relevant information out of a simple
string anyway.

I've looked through the scrollkeeper-devel and gnome-doc-list archives,
but I haven't been able to find any discussion that might explain these
very odd changes. Please enlighten me,


Martijn

Re: [Scrollkeeper-devel] omf encoding

[David M. <da...@lu...>]

On Thu, May 09, 2002 at 09:26:51PM -0600, John Fleck wrote:
> 
> Well, unless we're particularly industrious, we're restricted to the
> encodings supported by libxml2, which are the ones I listed above plus a
> couple that didn't seem particularly relevant. The full list*:
> 
>    1. UTF-8 is supported by default (null handlers)
>    2. UTF-16, both little and big endian
>    3. ISO-Latin-1 (ISO-8859-1) covering most western languages
>    4. ASCII, useful mostly for saving
>    5. HTML, a specific handler for the conversion of UTF-8 to ASCII with
> HTML predefined entities like © for the Copyright sign.
> 
> * http://www.xmlsoft.org/encoding.html
> 
> Beyond that, we'll have to write our own encoding converters.

FWIW, the LDP will sometime later this year include docs that need
Unicode. And Lampadas is using Unicode for i18n for that reason as
well. We have to support Chinese and Japanese, and Korean, and Arabic,
and Hebrew. So afaik that means Unicode.

-- 
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Lead Developer                                 http://www.tldp.org

A little rebellion now and then...is a medicine necessary for the sound
health of government.
	-- Thomas Jefferson

Re: [Scrollkeeper-devel] Clarification about language tag

[David M. <da...@lu...>]

On Mon, May 13, 2002 at 12:22:43AM -0500, Dan Mueth wrote:

> I always assumed the standard was to use the fallback locale, C, for
> documents in English, and that there wasn't much point in setting one's
> locale to 'en' or setting the locale in an OMF file to 'en'.  Of course
> English is my first language and I'm no expert on locales, so I may be
> missing something.  Is there a reason why we should install English 
> documents under both the C locale and en locale?  Or do some distributions 
> not put english documents in the C locale and instead put them under the 
> en locale?

C means the currently defined system locale. It just means "use the
default". It does not mean "use English".

I'm not an expert on locales either, although since the LDP is
involved in a massive i18n effort right now, I'm getting there!

IMO in SK they should be under en, not C. A document would never say
that its language is the default. No, a doc *has* a language! It is a
program config that might have as *its* configured locale, use the
default. Make sense?

-- 
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Lead Developer                                 http://www.tldp.org

Deep in the human unconscious is a pervasive need for a logical universe
that makes sense. But the real universe is always one step beyond logic.
	-- from "The Sayings of Muad'Dib" by the Princess Irulan

Re: [Scrollkeeper-devel] Re: omf encoding

[Dan M. <mu...@al...>]

On Fri, 10 May 2002, Karl Eichwalder wrote:

> Dan Mueth <mu...@al...> writes:
> 
> > Does anybody happen to know if there is a command-line tool to convert
> > files from one encoding to another, and one character set to another?
> 
> Use iconv (or recode).
>   I
> > Similarly, does anybody know of a tool for detecting the encoding and 
> > character set of a file?
> 
> Emacs tries guessing -- sometimes it fails, though.  AFAIK, you can
> only say something like: this is _not_ a UTF-8 files, but positive
> statements are not correct for 100% of all cases.


Thanks for the information Karl and John.

I updated the example OMF file to explicitly specify the encoding:

http://scrollkeeper.sourceforge.net/documentation/writing_scrollkeeper_omf_files/ar01s05.html

-Dan

Re: [Scrollkeeper-devel] Clarification about language tag

[Dan M. <mu...@al...>]

On 13 May 2002, Christian Marillat wrote:

> >> "DM" == Dan Mueth <mu...@al...> writes:
> 
> [...]
> 
> [SF seem to filter some doain name like wanaddo.fr, so I can't post to
> this list with my current address. Somebody konw where I can complain
> about this feature ?]

Is the wanaddo.fr email address subscribed?  I suspect the mailing list
only accepts posts from subscribers (although I'm not positive about
that).

> > On a technical level, it doesn't work because (a) we technically didn't
> > translate the categories into 'en', and (b) we don't list 'en' as one of
> > the supported locales. (We list the supported locales in
> > cl/templates/Makefile.am.)  So, supporting 'en' is about as hard as
> > writing the po file for it.
> 
> en is the same as C no ? 

Not precisely.  Most (all?) distributions and application packagers put 
all their English documents in the C locale.  My understanding is that 
C is just the fallback locale - if the user does not have a specified 
locale or an application is not localized into the user's locale, the C 
localization is used.  The convention is to use English for C.  Most 
people don't bother to create an en.po file since it is redundant. 
Similarly, I don't think anybody bothers to install documentation as if it 
were in the en locale, or write OMF files listing the locale as 'en'.  
Technically people could do all this, but I don't know of occasions where 
there is anything to gain by doing so since the fallback system defers to 
English anyway.

> About supported locale, if nobody is already working on French
> translation, I can do that.

Thanks :)

The current status of the French translation is:
184 translated messages, 3 fuzzy translations, 9 untranslated messages.

> > I always assumed the standard was to use the fallback locale, C, for
> > documents in English, and that there wasn't much point in setting one's
> > locale to 'en' or setting the locale in an OMF file to 'en'.  Of course
> > English is my first language and I'm no expert on locales, so I may be
> > missing something.  Is there a reason why we should install English 
> > documents under both the C locale and en locale?  Or do some distributions 
> > not put english documents in the C locale and instead put them under the 
> > en locale?
> 
> Read http://bugs.debia.org/144730 for full explanation.

I think ScrollKeeper is generally doing things properly.  The main thing
which is ambiguous (IMO) is how much ScrollKeeper should do locale
fallback and detection of user's locale. I used to think ScrollKeeper
should look at the locales and try to do the right things.  However, I now
think that ScrollKeeper is more of a database and should just keep track
of the data and leave the locale detection and fallback to the help
browser.  This way the browser can let the user configure what they want
using preferences instead of expecting everybody has their shell variables
and system configurations set up the right way.  It also makes sense when
you consider things like web application where there aren't meaningful
shell variables.  So, while ScrollKeeper currently *does* do locale 
fallback based on the environment variables, we may want to remove this in 
the future.

One thing which is messed up is that the way it is currently doing locale
fallback is pretty broken.  I need to review what exactly it is doing, but
it often doesn't work properly.  This may be contributing to the 
confusion.

Dan