scrollkeeper-devel — Developer discussion list for ScrollKeeper

[Scrollkeeper-devel] Release 0.1.3 of Scrollkeeper

[Laszlo K. <las...@Su...>]

Hi All,

Here is 0.1.3, a bug fix release.

Download area:

http://sourceforge.net/project/showfiles.php?group_id=11543&release_id=25886

Release Notes:

This is a bug fix release. Here are the more important bugs fixed:

- RPM update problem from 0.1.1 upwards fixed
- de, tr messages and translated trees added
- anchor tag related problem fixed
- -W flag added to the CVS build and all the warnings fixed
- sk.po updated
- OMF category set to a value not being in the tree so that the
Scrollkeeper doc does not get installed in the Scrollkeeper database as
it is incomplete

Laszlo

[Scrollkeeper-devel] Release 0.1.2 of Scrollkeeper

[Laszlo K. <las...@Su...>]

Hi,

Here is release 0.1.2.

Download area:

https://sourceforge.net/project/showfiles.php?group_id=11543

Release notes:

- post-install and post-uninstall messages removed from spec file
- Norwegian locales setup corrected (no, nn, nb, no_NY)
- messages about conflicting OMF files removed

Laszlo

[Scrollkeeper-devel] Release 0.1.1 of Scrollkeeper

[Laszlo K. <las...@Su...>]

Hello,

We just released Scrollkeeper 0.1.1.

Here is the download area:

https://sourceforge.net/project/showfiles.php?group_id=11543

Here is the Release Notes:

- multiple omf directory handling added; the OMF_DIR environment
variable has to be set to all the directories to be parsed (like PATH)
and scrollkeeper-rebuilddb run
- correct locale fallback implemented when looking for the right
category tree
- various translations added for category tree and messages
- loads of bug fixes, you can find out more about them from the bug
database and the ChangeLog

Laszlo

[Scrollkeeper-devel] localstatedir fun (was Re: gnome-utils omf/ScrollKeeper installation)

[Dan M. <da...@ea...>]

(I am cc'ing this to scrollkeeper-devel, just in case somebody there knows
the perfect solution.)

You need to set localstatedir to /var/lib.  For example, the spec file for
gnome-core uses:
%define localstatedir   /var/lib

Unfortunately, I can't find the perfect solution to this problem.  The FHS
says we should put things under /var.  However, we are not supposed to
make localstatedir default to /var because things are always supposed to
go under $prefix unless the builder explicitly states otherwise.  I see
this as an inconsistency between the autoconf concept that things always
go under $prefix and the FHS standard that things like /var and /etc are
not under $prefix.  So, I don't think there is any way to make everybody
happy at once.

I don't really like the fact that every package which has OMF metadata has
to be built with --localstatedir=/var/lib.  I'm not sure what the best
solution is though.

Another option would be to not use the -p option to scrollkeeper-update at
all.  In this case, scrollkeeper-update would use the default database
directory it was installed and configured with.  However, this means that
when one builds an RPM, it would try to update the existing database in
/var/lib.  While this is practically fine, it is conceptually broken.  
Further, it would not build a database under the RPMBUILDROOT, which is
also conceptually broken.  There is also some practical value to building
a fresh database under RPMBUILDROOT, as this may help one identify
breakage or view the database for debugging purposes.

So, I think the only solution which satisfies the idealogical constraints
of autoconf, building binary packages such as RPMs, and using the FHS
properly is the method we have chosen.  It has the unfortunate side effect
that people will have to start using --localstatedir=/var/lib for any
package which ships with OMF metadata.  I know this is lame, but I think
it is The Right Way, and I will point my finger at the FHS and autoconf
which seem to have different models for how things work.

Dan



On Mon, 19 Feb 2001, John Fleck wrote:

> Dan,
> I've turned on ScrollKeeper/omf installation in all of the docs
> directories in gnome-utils. I believe I've done it correctly, by
> copying exactly what you did in gnome-core. However, I get
> ScrollKeeper installation errors in both gnome-core and gnome-utils,
> as follows (at least the errors are identical :-):
> 
> >scrollkeeper-update -p /usr/var/scrollkeeper
> >mkdir: cannot make directory `/usr/var/scrollkeeper/TOC': No such
> >file or directory
> 
> Laszlo suggested this morning that I needed to set
> --localstatedir=/var in autogen.sh. That also did not work:
> 
> >scrollkeeper-update -p /var/scrollkeeper
> >mkdir: cannot make directory `/var/scrollkeeper/TOC': No such file or
> >directory
> 
> I'm guessing it needs to be --localstatedir=/var/lib, which is where
> the scrollkeeper stuff actually is? Or do I have a problem in my
> scrollkeeper installation?
> 
> Cheers,
> 

[Scrollkeeper-devel] Web Pages, Bugs, and Versioning

[Dan M. <da...@ea...>]

Web Pages
---------
I just made a few minor updates to the web pages to bring them back up to
date:
http://scrollkeeper.sourceforge.net

Bugs
----
I also thought I should mention that we are now using the bug tracking
system on SourceForge.

Versioning
----------
Just to be sure everybody understands where we are at, and to clarify the
versioning will be made to sync up with the Linux kernel conventions:

0.1.0:
We just put out scrollkeeper-0.1.0.  This is the minimally functional
release, including i18n.  It basically can present the help browser with a
list of documents on the system, sorted by document category.  It also
reads the table of contents for DocBook/SGML files and can return this
inside the contents tree.

0.1.x:
These will be bug fix releases, for final stabalization for 0.2.0.  We
have already done some testing for 0.1.0, but we have the start of a real
test plan which we hope to fill out and use to qualify scrollkeeper as
ready to ship as 0.2.0.

0.2.0:
Our first "stable" release.  This is the same as 0.1.0, but will have bug
fixes and documentation/translation improvements.

0.2.x:
These are of course bug fixes we may have missed in 0.2.0.

0.3.0:
Woohoo - new features.  We haven't determined which features we get to add
to 0.3.0 yet, but as soon as 0.2.0 or maybe 0.2.1 goes out, we can resume
this discussion.

Dan

[Scrollkeeper-devel] Release 0.1.0 of Scrollkeeper

[Laszlo K. <las...@Su...>]

Hi,

There have been two new releases in the last 3 days. Here are the
release notes:

- OMF directory is $datadir/omf instead of $prefix/doc/omf
- sv_SE locale added
- improved category tree

Download area is:

https://sourceforge.net/project/showfiles.php?group_id=11543

Laszlo

[Scrollkeeper-devel] release 0.0.5 of Scrollkeeper

[Laszlo K. <las...@Su...>]

Hello,

Two new releases followed each other in one day. The latest one is
0.0.5. 0.0.4 has important features. Here are the release notes for
both:

0.0.5:
This release has a new and improved spec files so that RPMs do the right
thing when upgrading between versions. Prior versions did not always
work well if the user upgraded from one RPM to another (especially 0.0.3
to 0.0.4). Basically, if you have a ScrollKeeper RPM prior to 0.0.5, you
have to first do "rpm -e scrollkeeper" before installing the new
scrollkeeper. -Dan 


0.0.4:
There are two main features added in this release:
   - internationalization: this includes full gettext() support for the
messages and separate template trees being installed for every locale,
translation is not done yet

- recursive parsing of the OMF directory, this makes possible any kind
of grouping of OMF files in subdirectories related to packages or
locales to avoid collision

Link for download:

http://sourceforge.net/project/showfiles.php?group_id=11543

Scroll down a bit for Release 0.0.5 as Dan's computer time was not set
up correctly when he created the release:-)

Laszlo

[Scrollkeeper-devel] Meta Project - early demo

[Rich M. <rd...@cf...>]

As a way to try out some of the ideas in the Meta Project, I am building
a demonstration browser.  Specifically, it is a CGI script that can look
up related files, directories, and documentation for a specified item.

The demo is very limited (it only covers the FreeBSD 4.1 distributed file
system), but I think it starts to demonstrate the utility of integrating
system metadata and documentation.

Please take a look at the demo, then let me know (off the list, please :-)
what you think.  The best starting point is the Meta Demo Help Page:

   http://www.cfcl.com/rdm/Meta/mdhelp.html

-r
-- 
--
http://www.cfcl.com/rdm
email: rd...@cf...
phone: +1 650-873-7841

Re: [Scrollkeeper-devel] Scrollkeeper 0.0.3 released

[Laszlo K. <las...@su...>]

> Could you include the release notes in the future? ;) I just find it
> annoying to be forced to go to a link from a mail (esp. since I usually
> download mail while online and then read offline).
> 
> Regards,
> Ali
> 

Sure.

Laszlo

Re: [Scrollkeeper-devel] Scrollkeeper 0.0.3 released

[Ali A. <ali...@au...>]

> Hi,
>
> Scrollkeeper 0.0.3 was just released. Changes are quite minor.
>
> Here are the files:
>
> http://sourceforge.net/project/showfiles.php?group_id=11543
>
> And here are the Release Notes:
>
> http://sourceforge.net/project/shownotes.php?release_id=21872
>
> Enjoy:-)

Could you include the release notes in the future? ;) I just find it
annoying to be forced to go to a link from a mail (esp. since I usually
download mail while online and then read offline).

Regards,
Ali

[Scrollkeeper-devel] Scrollkeeper 0.0.3 released

[Laszlo K. <las...@su...>]

Hi,

Scrollkeeper 0.0.3 was just released. Changes are quite minor.

Here are the files:

http://sourceforge.net/project/showfiles.php?group_id=11543

And here are the Release Notes:

http://sourceforge.net/project/shownotes.php?release_id=21872

Enjoy:-)

Laszlo

[Scrollkeeper-devel] testing

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

Sorry for the spam, I didn't get Laszlo's last message, so I want to
make sure I'm still getting mail from here.  Thanks,

    Greg

[Scrollkeeper-devel] roadmap draft

[Laszlo K. <las...@su...>]

Hello,

This is a roadmap draft I put together about future Scrollkeeper
development. It wrote up where we would like to develop Scrollkeeper to
the best of my knowledge using the information from the mailing list.

It would make us help to structure and hopefully speed up the
development.

When we can agree on a final form, we should use that as a frame for
future development.

Please read it and let me know what you think.


Thanks,

Laszlo

Re: [Scrollkeeper-devel] Re: Does Simple-URI equal URN?

[Laszlo K. <las...@su...>]

I think this should be answered by people who know more about the
Simple-URI scheme than I do.

Laszlo

> 
> I'm not sure what to make of the total lack of response
> to my 7 December posting about URNs. Did everyone feel it
> was too tangential?  Too complicated?  Too busy to respond?
> 
> Not that everything I say deserves comment,  8^)
> but I specifically put that suggestion up for comment.
> 
> bobs

[Scrollkeeper-devel] Incomplete archive

[Laszlo K. <las...@su...>]

Hi,

The archive available from this link (the one from
scrollkeeper.sourceforge.net)

http://lists.sourceforge.net/mailman/listinfo/scrollkeeper-devel

does not contain the last couple of messages from December. They are
accesible though through the Sourceforge project page. Anybody knows why
do we have this problem?

Laszlo

Re: [Scrollkeeper-devel] compile problem

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

On Mon, 18 Dec 2000, Bob Stayton wrote:

> Thanks for clarifying.  The libxml on this system
> is indeed 2.0.0, as shown by 'rpm -q libxml'.
> It does not work with scrollkeeper. Looks like I need
> to upgrade to an *older* libxml.  8^)
> 

This has been a bit of a frustration, because some of the neat stuff is in
the 2.* libxml, but Gnome will not emmigrate to that promised land
until after Gnome 1.4. I assume this is why Scrollkeeper was written
against the older libxml.

cheers,

John Fleck

Re: [Scrollkeeper-devel] compile problem

[Bob S. <bo...@sc...>]

> From: Gregory Leblanc <gle...@cu...>
> 
> On 18 Dec 2000 09:52:39 -0800, Bob Stayton wrote:
> > I'm downloaded scrollkeeper-0.0.2.tar.tz, but I'm not
> > able to compile it on my system (Caldera LTP).  Configure runs
> > OK, but when I run make, I get:
> > 
> > make[3]: Entering directory `/home/bobs/scrollkeeper-0.0.2/cl/src'
> > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/libxml -I/usr/include    -g -
> > O2 -c preinstall.c
> > preinstall.c: In function `update_doc_url_in_omf_file':
> > preinstall.c:39: structure has no member named `childs'
> > 
> > If I look in /usr/include/libxml where the structure xmlNodePtr
> > should be defined, I see that it has no "childs" member.  I have
> > a feeling I have the wrong libxml.  I need the Gnome libxml,
> > right?  The files in my /usr/include/libxml seem to have come
> > from W3C.  
> 
> libxml is written by Daniel Veillard (no, I can't speel in english, let
> alone french), who works for the w3c.  The package is "sort of" under
> the auspices of GNOME, but probably because at the time he developed it,
> there weren't other alternatives that were so open.  
> Ok, enough politics, time to fix the problem.  IIRC, Caldera uses RPM.
> Did you install your copy of libxml from RPM?  If so, try 'rpm -q
> libxml' to find out what version you have.  If you installed libxml from
> a tarball, try looking at the libraries that it installed, probably in
> /usr/lib.  (called libxml.so.?.?.?).  The very latest and greates is
> libxml 1.8.10, although there is a libxml 2 available as well.  I don't
> think libxml 2 will work with scrollkeeper.
> Upgrading to a newer libxml (rpmfind.net is your friend) should fix
> things, but I'm curious as to what version you have that is causing this
> to break.

Thanks for clarifying.  The libxml on this system
is indeed 2.0.0, as shown by 'rpm -q libxml'.
It does not work with scrollkeeper. Looks like I need
to upgrade to an *older* libxml.  8^)

bobs
Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The Santa Cruz Operation, Inc.              fax:   (831) 429-1887
                                            email: bo...@sc...

Re: [Scrollkeeper-devel] compile problem

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

On 18 Dec 2000 09:52:39 -0800, Bob Stayton wrote:
> I'm downloaded scrollkeeper-0.0.2.tar.tz, but I'm not
> able to compile it on my system (Caldera LTP).  Configure runs
> OK, but when I run make, I get:
> 
> make[3]: Entering directory `/home/bobs/scrollkeeper-0.0.2/cl/src'
> gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/libxml -I/usr/include    -g -
> O2 -c preinstall.c
> preinstall.c: In function `update_doc_url_in_omf_file':
> preinstall.c:39: structure has no member named `childs'
> 
> If I look in /usr/include/libxml where the structure xmlNodePtr
> should be defined, I see that it has no "childs" member.  I have
> a feeling I have the wrong libxml.  I need the Gnome libxml,
> right?  The files in my /usr/include/libxml seem to have come
> from W3C.  

libxml is written by Daniel Veillard (no, I can't speel in english, let
alone french), who works for the w3c.  The package is "sort of" under
the auspices of GNOME, but probably because at the time he developed it,
there weren't other alternatives that were so open.  
Ok, enough politics, time to fix the problem.  IIRC, Caldera uses RPM.
Did you install your copy of libxml from RPM?  If so, try 'rpm -q
libxml' to find out what version you have.  If you installed libxml from
a tarball, try looking at the libraries that it installed, probably in
/usr/lib.  (called libxml.so.?.?.?).  The very latest and greates is
libxml 1.8.10, although there is a libxml 2 available as well.  I don't
think libxml 2 will work with scrollkeeper.
Upgrading to a newer libxml (rpmfind.net is your friend) should fix
things, but I'm curious as to what version you have that is causing this
to break.


    Greg

[Scrollkeeper-devel] compile problem

[Bob S. <bo...@sc...>]

I'm downloaded scrollkeeper-0.0.2.tar.tz, but I'm not
able to compile it on my system (Caldera LTP).  Configure runs
OK, but when I run make, I get:

make[3]: Entering directory `/home/bobs/scrollkeeper-0.0.2/cl/src'
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/libxml -I/usr/include    -g -
O2 -c preinstall.c
preinstall.c: In function `update_doc_url_in_omf_file':
preinstall.c:39: structure has no member named `childs'

If I look in /usr/include/libxml where the structure xmlNodePtr
should be defined, I see that it has no "childs" member.  I have
a feeling I have the wrong libxml.  I need the Gnome libxml,
right?  The files in my /usr/include/libxml seem to have come
from W3C.  

Any help in resolving this would be appreciated.

bobs
Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The Santa Cruz Operation, Inc.              fax:   (831) 429-1887
                                            email: bo...@sc...

[Scrollkeeper-devel] Release 0.0.2 of Scrollkeeper

[Laszlo K. <las...@su...>]

Hi,

We just released version 0.0.2 of Scrollkeeper. Changes from 0.0.1 are:

- A manual (in DocBook/SGML) was added to Scrollkeeper with OMF metadata
set up
- The category field in the OMF file (the one that specifies where the
doc goes in the content list) was changed according to the following
definition:

<subject>
  <category>Applications|Graphics|Editors</category>
  <category>Development|Kernels|FreeBSD</category>  
</subject>

This spec means that the doc goes into:

Applications
    Graphics
	Editors

and 

Development
    Kernels
	FreeBSD

'|' is the separator of categories.

The Scrollkeeper manual has its category set to "Scrollkeeper" which is
not present in our enforced category tree so this doc will not be added
to the category tree. Use hello-world-1 for these type of tests.

Release 0.0.2 is available at:

http://sourceforge.net/project/showfiles.php?group_id=11543

Note that this is not the same as the ftp site for release 0.0.1.

Both Scrollkeeper and the hello-world-1 application were updated.

Scrollkeeper 0.0.2 is not compatible with Scrollkeeper 0.0.1.

Enjoy and send in many feedbacks.

I am of for this year so happy holidays for everybody.

Laszlo

[Scrollkeeper-devel] Re: Does Simple-URI equal URN?

[Bob S. <bo...@sc...>]

I'm not sure what to make of the total lack of response
to my 7 December posting about URNs. Did everyone feel it
was too tangential?  Too complicated?  Too busy to respond?

Not that everything I say deserves comment,  8^)
but I specifically put that suggestion up for comment.

bobs
Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The Santa Cruz Operation, Inc.              fax:   (831) 429-1887
                                            email: bo...@sc...

Re: [Scrollkeeper-devel] Release 0.0.1 of Scrollkeeper

[Laszlo K. <las...@su...>]

> > 1. The output of Scrollkeeper is a set of XML files. They are in
> > $localstatedir/lib/scrollkeeper. A patch was submitted for the new Gnome
> > Help System (Nautilus, Hyperbola component) to support Scrollkeeper.
> > This is the only help browser that supports Scrollkeeper at the moment.
> > The patch was accepted, but the reviewers requested this release
> > announcement (and tarball and RPMs) for the integration. As soon as that
> > patch is integrated, the system should be fully working (I will send an
> > email here when the integration happens.
> 
> Just like to point out to people that this will be disabled by default (as per
> a private discussion between Laszlo and another Sun employee (Mark)). So
> touting Nautilus was the 'first system to support Scrollkeeper' is slightly
> misleading.

I am not very good in using mixed tenses correctly in English:-) You are
right with the above.

> 
> Secondly, if you decide to enable it (it would require you to #define
> something in the code) realize that we not realizing the full potential of
> Scrollkeeper.

Correct.

Laszlo

Re: [Scrollkeeper-devel] Release 0.0.1 of Scrollkeeper

[Ali A. <ali...@au...>]

* Laszlo Kovacs (las...@su...) wrote at 02:29 on 11/12/00:
> Hello,
> 
> This is the official announcement of the first ever Scrollkeeper release
> 0.0.1. The tarball and source and binary RPMs can be found at:
> 
> ftp://scrollkeeper.sourceforge.net/pub/scrollkeeper/
> 
> An example application called hello-world-1 is also available there
> (tarball, source and binary RPM). 
> 
> This version of Scrollkeeper implements proposal #3 for this project.
> The proposal itself is here:
> 
> http://www.geocrawler.com/archives/3/6429/2000/11/50/4650283/
> 
> Two things to be noted:
> 
> 1. The output of Scrollkeeper is a set of XML files. They are in
> $localstatedir/lib/scrollkeeper. A patch was submitted for the new Gnome
> Help System (Nautilus, Hyperbola component) to support Scrollkeeper.
> This is the only help browser that supports Scrollkeeper at the moment.
> The patch was accepted, but the reviewers requested this release
> announcement (and tarball and RPMs) for the integration. As soon as that
> patch is integrated, the system should be fully working (I will send an
> email here when the integration happens.

Just like to point out to people that this will be disabled by default (as per
a private discussion between Laszlo and another Sun employee (Mark)). So
touting Nautilus was the 'first system to support Scrollkeeper' is slightly
misleading.

Secondly, if you decide to enable it (it would require you to #define
something in the code) realize that we not realizing the full potential of
Scrollkeeper. 
 
> 2. In order to have Scrollkeeper working properly it's localstatedir has
> to be /var. This should be the same for any applications that rely on
> Scrollkeeper handling their OMF files. This is a general recomandation
> for any application running on Linux anyway.

Hmmm - need to verify that Nautilus conforms to this.

Regards,
Ali

[Scrollkeeper-devel] Release 0.0.1 of Scrollkeeper

[Laszlo K. <las...@su...>]

Hello,

This is the official announcement of the first ever Scrollkeeper release
0.0.1. The tarball and source and binary RPMs can be found at:

ftp://scrollkeeper.sourceforge.net/pub/scrollkeeper/

An example application called hello-world-1 is also available there
(tarball, source and binary RPM). 

This version of Scrollkeeper implements proposal #3 for this project.
The proposal itself is here:

http://www.geocrawler.com/archives/3/6429/2000/11/50/4650283/

Two things to be noted:

1. The output of Scrollkeeper is a set of XML files. They are in
$localstatedir/lib/scrollkeeper. A patch was submitted for the new Gnome
Help System (Nautilus, Hyperbola component) to support Scrollkeeper.
This is the only help browser that supports Scrollkeeper at the moment.
The patch was accepted, but the reviewers requested this release
announcement (and tarball and RPMs) for the integration. As soon as that
patch is integrated, the system should be fully working (I will send an
email here when the integration happens.

2. In order to have Scrollkeeper working properly it's localstatedir has
to be /var. This should be the same for any applications that rely on
Scrollkeeper handling their OMF files. This is a general recomandation
for any application running on Linux anyway.

Thank you for everybody who helped in the various stages of the project.
Please give it a try and tell us how you find it.

Thanks,

Laszlo

[Scrollkeeper-devel] Does Simple-URI equal URN?

[Bob S. <bo...@sc...>]

> From: Dan Mueth <d-...@uc...>
>
> You don't typically want the completely unique identification (UUID is for
> {document, language, version, format}, but the document identifier (NUID
> is what I called it) {document but not language, version, or format}.  
> This would be mapped onto names to make things "nice" like IP addresses
> are mapped onto names.  Of course we won't use a DNS server - we'd put the
> name into the metadata and use a database on the web for reference use
> only.  It would still be a "first come, first serve" basis for giving out
> names (like domain names), although inappropriate use would be frowned
> upon of course.

This unique ID is sounding a lot like the Uniform Resource Name (URN)
effort at IETF and W3C.  Various parties have been trying to settle
on a standard for identifying a given resource with a single
stable ID name, which can then be mapped in some fashion to
an address (or addresses).  They are trying to solve the
same problem of creating logical cross references (stable) instead
of hard-coded address references (unstable).

Here are the stated requirements for URNs:
(From: <http://www.dlib.org/dlib/february96/02arms.html>)

- "Global scope: A URN is a name with global scope which does
not imply a location. It has the same meaning everywhere. 

- "Global uniqueness: The same URN will never be assigned to
two different resources. 

- "Persistence: It is intended that the lifetime of a URN be
permanent. That is, the URN will be globally unique forever,
and may well be used as a reference to a resource well
beyond the lifetime of the resource it identifies or of any
naming authority involved in the assignment of its name. 

- "Scalability: URNs can be assigned to any resource that
might conceivably be available on the network, for hundreds
of years. 

- "Legacy support: The scheme must permit the support of
existing legacy naming systems, insofar as they satisfy the
other requirements described here. ... 

- "Extensibility: Any scheme for URNs must permit future
extensions to the scheme. 

- "Independence: It is solely the responsibility of a name
issuing authority to determine the conditions under which it
will issue a name." 

The URN effort has been going on since 1994
without yet producing a real standard.  As far
as I can tell, the only de facto standard is the IETF
RFC 2141 "URN Syntax" at <http://www.ietf.org/rfc/rfc2141.txt>.
I think the general global solution must be a hard
problem.  There is certainly plenty of material to
study at www.w3.org on URNs.

But the URN syntax could be used for Dan's suggested SK
identifier.  In fact, OMF already seems to support it.
Looking at the OMF Template form at
<http://www.ibiblio.org/osrt/omf/cgi-bin/template.pl?verflag=1>
I see that they define the <identifier> element as "a
unique ID by which the resource may be identified and from
which the resource may be retrieved (e.g. a URL or URN)."

Also, the OMF DTD says that all elements can be repeated
for a resource.  That means a resource could have one
<identifier> for its URI and another <identifier>
containing its URN.  Add yet another to fall back to
the source site, if necessary.

The URN syntax is pretty simple.  From the RFC:

   <URN> ::= "urn:" <NID> ":" <NSS>

   where <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading "urn:" sequence is case-insensitive.
   The Namespace ID determines the _syntactic_ interpretation of the
   Namespace Specific String

The OMF project, which is setting itself up as the
centralized cataloging site, would define the Namespace as
perhaps "omf:".  Then OMF would assign and regulate
Namespace Specific Strings, which are the names that
Dan has proposed.  So a simplified URN for a Linux man page
might look something like <urn:omf:linux.man1.ls>.  Of
course, the trick is still assigning unique names for the
third field (please don't take my example as a literal
suggestion for a naming scheme).  The OMF naming scheme
would have to take into account the many factors that have
already been discussed.  But the OMF would have the final
authority since its namespace would be used.  Using an OMF
namespace reduces the problem of a unique id from
globally-unique to OMF-unique, a far simpler problem.

You might think having two <identifier> elements would
be confusing, but each is recognizable by its own
protocol, as in this example:

<resource>
 <title>ls manual page</title>
 <identifier>urn:omf:linux.man1.ls</identifier>
 <identifier>file:/usr/share/man/man1/ls.1</identifier>
 <identifier>http://www.linuxdoc.org/man/man1/ls</identifier>
</resource>

Any document could cross reference to an OMF-registered
document's URN.  If an SK-aware browser was reading a
document with a cross reference to a URN, it could look in
its metadata set to see if that urn:<identifier> also had a
file:<identifier>.  If not, it could fall back to an
http:<identifier> if it were available.  As a last resort,
the browser would query the OMF site for the latest
resolution of that URN.  

I went a little further and checked the Dublin Core
Metadata Element Set, on which OMF is based.
Their definition of the <identifier> element is
"An unambiguous reference to the resource
within a given context.  Comment:  Recommended best
practice is to identify the resource by means of a string
or number conforming to a formal identification system.
Example formal identification systems include the Uniform
Resource Identifier (URI) (including the Uniform Resource
Locator (URL)), the Digital Object Identifier (DOI) and the
International Standard Book Number (ISBN)."

Dublin Core doesn't mention URNs, probably because they aren't
recognized as a formal standard.   There is no global
registration and resolution mechanism for the Namespace
part of a URN, so one cannot rely on a URN being
resolved in all contexts.  But within the "given context"
of an SK metadata set, the omf: namespace has sufficient
meaning to be resolved.

My point of all this verbiage is that I think OMF already
has a mechanism for these unique names, although I am not
suggesting the actual naming scheme.  I also wanted
to make sure this scheme stays within the RDF standard
so that RDF tools can be used to process them. 

Comments?

bobs
Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The Santa Cruz Operation, Inc.              fax:   (831) 429-1887
                                            email: bo...@sc...