scrollkeeper-devel

Re: [Scrollkeeper-devel] Better internationalization support

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

> From: Laszlo Kovacs <las...@su...>
> 
> > In December, I posted an alternative approach
> > using URNs.  
> > [stuff deleted]
> 
> I read that email back in December, but this explanation above seems to
> clarify loads of things. I think I like this idea. At the bottom of your
> previous email you suggested that omf should be the namespace for every
> document handled by Scrollkeeper. I think it would be better if this
> would be named after the organization or project who produces the ID.
> Like urn:gnome:... or urn:kde:... . If we use omf for namespace then I
> think we will need to validate the URNs used by developers of various
> projects, while otherwise this would be done by them. We just need to
> publish a description about how the URNs should be created.

Yes, I agree.  
 
> If we do it like this then we just have to publish this recommendation
> and we are done. And I can start development:-)
> 
> Note that I still see this mainly as support for identifying a doc and
> all its translations uniquely. So these documents should all hold the
> same id. Therefore using the <identifier> tag from OMF might not be the
> best for this as the only way I can figure out that this is the ID that
> is the same for the doc and all its translations is that it begins with
> the word "urn". If we want to use URNs later for something else then we
> would be in trouble, I think. It could be something like
> urn:translation:... so we know that this URN is for translation
> identification. In which case only the last part of the URN is available
> to identify the doc and that might not be enough to keep the uniqueness
> of the ID. 
> 
> But I really think generally this is the way to go.
> 
> Thoughts?

I read the OMF element descriptions again and I think
we need to be careful how we use the <identifier> element.
According to the description, <identifier> is a URI
that points to a unique document.  Since <identifier> is part
of an OMF record, and since an OMF record also has
elements for the document's language, version, and
format, I interpret the <identifier> element to be
a reference to one combination of
document+language+version+format.  Each such combination
would have its own OMF record.

But you would like to be able to use a fallback mechanism
that permits providing access to alternate versions,
languages, or formats, depending on the needs of the user,
right?

A simple URN like <urn:kde:GetStart> is really an abstract
reference to the collection of all combinations of
language+version+format for the KDE getting started guide.
If the identifier is in a parsible format, such as
name+language+version+format, then it is unique and yet it
can be picked apart as needed for fallback along
any of the dimensions.  

Using a fixed field format:

<urn:kde:GetStart+en+3.1+pdf>

or maybe a more flexible URL syntax which identifies
each field:

<urn:kde:GetStart?lang=en&version=3.1&format=pdf>

You want the French version?  Then find the OMF record
whose urn substitutes lang=fr, possibly with some
flexibility in version (in case the latest english
version hasn't been translated) and format.

Special characters would be escaped with %XX.
Kind of ugly, but I guess not any uglier than a UUID. 8^)

I also note that <identifier> is a repeatable element in
the OMF DTD.  That means an OMF record could have one
<identifier> whose attribute is an http: address and
another using the urn: prefix to provide this other
information.

So now I've turned a simple scheme into a more complicated
one, but it is more rigorous and I think meets the
needs for a fallback mechanism.

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] Better internationalization support

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

> From: Dan Mueth <da...@ea...>
> 
> On Wed, 18 Apr 2001, Bob Stayton wrote:
> 
> > I read the OMF element descriptions again and I think
> > we need to be careful how we use the <identifier> element.
> > According to the description, <identifier> is a URI
> > that points to a unique document.  Since <identifier> is part
> > of an OMF record, and since an OMF record also has
> > elements for the document's language, version, and
> > format, I interpret the <identifier> element to be
> > a reference to one combination of
> > document+language+version+format.  Each such combination
> > would have its own OMF record.
> > 
> > But you would like to be able to use a fallback mechanism
> > that permits providing access to alternate versions,
> > languages, or formats, depending on the needs of the user,
> > right?
> > 
> > A simple URN like <urn:kde:GetStart> is really an abstract
> > reference to the collection of all combinations of
> > language+version+format for the KDE getting started guide.
> > If the identifier is in a parsible format, such as
> > name+language+version+format, then it is unique and yet it
> > can be picked apart as needed for fallback along
> > any of the dimensions.  
> > 
> > Using a fixed field format:
> > 
> > <urn:kde:GetStart+en+3.1+pdf>
> > 
> > or maybe a more flexible URL syntax which identifies
> > each field:
> > 
> > <urn:kde:GetStart?lang=en&version=3.1&format=pdf>
> 
> Everything you say seems right, and this approach should work. (Although I
> think a couple small details of the syntax would have to be
> changed: http://www.ietf.org/rfc/rfc2141.txt .)
> 
> This would solve a few problems at once - the unique id, the document set
> id, and it would allow us to integrate with the URN resource location
> system.
> 
> It seems somewhat complicated though and would be a substantial amount of
> work to achieve.  We would have to go through the application and review
> procedure to get our NID, which I'm guessing is enough trouble that few
> people would want to get their own NID.  Then, we would have to actively
> manage a pretty large set of NSS's.  This would probably only be tractable
> if we had an automatic system to handle requests.
> 
> If we just wanted to solve the document set id problem, then using uuidgen
> would be a much simpler solution, both as an organization and for
> individuals.  So, whether we would use something like this largely comes
> down to how important it is that we adopt the URN system for its own
> value.  I don't know enough about the URN system to know how widely
> adopted it is or what tools exist to take advantage of it.  Could you fill
> us in here?  
>
> Do DNS servers currently support URN's?
> 
> Note we could still use the URN system with uuidgen:
> 
> "urn:gnome.org:`uuidgen`"
> 
> which would remove most of the admin headache.  We would need a seperate
> id using uuidgen for the document groups (all formats, locales, and
> versions of a document).

I did some more research on URNs.  The first thing I learned
is that there is no universal system in place for resolving
URNs over the Internet.  The DNS resolution protocol described
in RFC2168 (June 1997) appears to have never gotten past the
Experimental stage.  

I wasn't really thinking in terms of Internet resolution
of URNs, just using the URN syntax to define unique OMF
identifiers.  I found RFC 2611 "URN Namespace
Definition Mechanisms" (June 1999) that provides guidance
for doing that.  Section 4.0 defines three categories
of URN namespaces:

I. Experimental: which are not registered with IANA.
They take the form "X-anyname". There is no provision
for avoiding collisions. They are intended for use within
internal or limited experiemental contexts.

II.  Informal: which are registered with IANA, and
take the form "urn-number", where the number is assigned
by IANA.

III. Formal: which are registered with IANA, and where 
you get to pick the name.  The catch is that it is
processed through an RFC review process, although not
"standards-track".  There seem to be very few RFCs 
requesting formal URNs.

The first category (X-name) would permit us to
use URNs in a valid fashion, yet avoid the need
to register a namespace.  Registration doesn't gain us much if
there is no global resolution mechanism.  Experimental
namespaces define their own mechanism for resolving
items in their name space.  OMF URNs would only
be resolvable in the OMF scope, but that would work
for ScrollKeeper.  So a valid NID could be "x-omf".

I also found examples of namespaces that use ":" to
separate fields in their NSSs (the part after the
namespace in the URN).  So rather than proliferate
organization NIDs, we could make it part of
the NSS in a single x-omf namespace:

urn:x-omf:organization:name:version:language:format
    <-->  <--------------------------------------->
    NID                   NSS

So this would be a valid URN that uniquely identifies
a document for a given version, language, and format:

  urn:x-omf:kde.org:GetStart:1.2:en:html

You could use a fragment of this to reference what you
call a document group:

  urn:x-omf:kde.org:GetStart 

refers to all versions, languages, and formats of the
KDE Getting Started guide.    

This syntax could also be useful for queries:

  urn:x-omf:kde.org:GetStart:*:fr:*

which requests any french version of the document,
perhaps defaulting to the latest HTML version in 
the context of ScrollKeeper.

Managing this single namespace would be up to OMF.
They would assign organization subspaces, without
a need for IANA or RFCs.  Those organizations would
assign their document names in a unique fashion.  

In the future, if this experimental namespace
proves valuable and some global resolution
mechanism becomes available, OMF could apply for
a formal namespace identifier.

Coments?

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] Better internationalization support

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

> I did some more research on URNs.  The first thing I learned
> is that there is no universal system in place for resolving
> URNs over the Internet.  The DNS resolution protocol described
> in RFC2168 (June 1997) appears to have never gotten past the
> Experimental stage.
> 
> I wasn't really thinking in terms of Internet resolution
> of URNs, just using the URN syntax to define unique OMF
> identifiers.  I found RFC 2611 "URN Namespace
> Definition Mechanisms" (June 1999) that provides guidance
> for doing that.  Section 4.0 defines three categories
> of URN namespaces:
> 
> I. Experimental: which are not registered with IANA.
> They take the form "X-anyname". There is no provision
> for avoiding collisions. They are intended for use within
> internal or limited experiemental contexts.
> 
> II.  Informal: which are registered with IANA, and
> take the form "urn-number", where the number is assigned
> by IANA.
> 
> III. Formal: which are registered with IANA, and where
> you get to pick the name.  The catch is that it is
> processed through an RFC review process, although not
> "standards-track".  There seem to be very few RFCs
> requesting formal URNs.
> 
> The first category (X-name) would permit us to
> use URNs in a valid fashion, yet avoid the need
> to register a namespace.  Registration doesn't gain us much if
> there is no global resolution mechanism.  Experimental
> namespaces define their own mechanism for resolving
> items in their name space.  OMF URNs would only
> be resolvable in the OMF scope, but that would work
> for ScrollKeeper.  So a valid NID could be "x-omf".
> 
> I also found examples of namespaces that use ":" to
> separate fields in their NSSs (the part after the
> namespace in the URN).  So rather than proliferate
> organization NIDs, we could make it part of
> the NSS in a single x-omf namespace:
> 
> urn:x-omf:organization:name:version:language:format
>     <-->  <--------------------------------------->
>     NID                   NSS
> 
> So this would be a valid URN that uniquely identifies
> a document for a given version, language, and format:
> 
>   urn:x-omf:kde.org:GetStart:1.2:en:html
> 
> You could use a fragment of this to reference what you
> call a document group:
> 
>   urn:x-omf:kde.org:GetStart
> 
> refers to all versions, languages, and formats of the
> KDE Getting Started guide.
> 
> This syntax could also be useful for queries:
> 
>   urn:x-omf:kde.org:GetStart:*:fr:*
> 
> which requests any french version of the document,
> perhaps defaulting to the latest HTML version in
> the context of ScrollKeeper.
> 
> Managing this single namespace would be up to OMF.
> They would assign organization subspaces, without
> a need for IANA or RFCs.  Those organizations would
> assign their document names in a unique fashion.
> 
> In the future, if this experimental namespace
> proves valuable and some global resolution
> mechanism becomes available, OMF could apply for
> a formal namespace identifier.
> 
> Coments?
> 

Bob,

We discussed this on IRC yesterday and we decided to go this way (per
your suggestion):
 
urn:x-omf:organization:name:version:language:format
    <-->  <--------------------------------------->
    NID                   NSS

This will give us a unique ID and a non-unique ID also. At the moment it
will be the docwriters, developers task to manage their namespaces. I
think we will write up a recomendation of how to do it so that the URNs
will be as unique as possible. I raised during the discussion that we
could have another field between "organization" and "name" like
"package" or "project" or a more generic one like "group". I also
thought this morning that we might end up with having to modify the
structure of the NSS which would be a problem with maintaining
compatibility at the same time. So I thought maybe an OMF URN version
field should be added, like:

urn:x-omf:omf-urn-version:organization:group:name:version:language:format 

where omf-urn-version is for internal purpose to track changes in our
URN structure. Although we could also use x-omf1, x-omf2 etc instead of
x-omf. Do people think this would be useful?

Laszlo

Re: [Scrollkeeper-devel] Better internationalization support

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

On Fri, 20 Apr 2001, Laszlo Kovacs wrote:

> So I thought maybe an OMF URN version field should be added, like:
> 
> urn:x-omf:omf-urn-version:organization:group:name:version:language:format 
> 
> where omf-urn-version is for internal purpose to track changes in our
> URN structure. Although we could also use x-omf1, x-omf2 etc instead of
> x-omf. Do people think this would be useful?

So, we would have:

urn:x-omf1:organization:group:name:version:language:format

where organization will normally be a domain and group is whatever the
coordinators for that domain choose (package, project, etc.)

The part of this which will be used to identify a series of a document
(different versions, formats, and languages) is:

urn:x-omf1:organization:group:name

Note that this means that a document cannot be moved between organizations
or groups or it will lose its "identity". (eg. an organization changes its
name, a document changes groups such as by being moved into a different
package, etc. ) The versions before the move will belong to a different
series from those versions after the move.  Fundamentally, the part of the
URN which describes the series should never change, even if the old labels
no longer accurately describe the document, because this part of the URN
is being used to identify the document series.

So, we have a few choices here:

1) Use the URN's as if they are metadata and change the URN if the
organization, doc name, or doc group changes.  This undermines the purpose
of having a document series identifier.  We could do it anyway and just
live with a certain level of breakage in the system, but this does not
seem like The Right Way.  

2) Try to enforce that once the document series portion of the URN is set,
it should not be changed.  This is the behavior one expects from a
document series identifier.  However, it seems odd since the URN looks
like metadata and people would not want "incorrect" metadata.  Plus, most
people will probably not realize they should not change this part and
change it anyway.

3) Go back to using the uuidgen system (or some other system) for series
id's.  Note that we may still use URN's for unique document identifiers.
We would be going back to the original plan of having two identifiers: one
for the doc series and one as a unique resource identifier.  If we do
this, we would have to seperately evaluate whether URN's or uuidgen are
better for the unique document identifiers.

4) ???

Although I had really warmed up to the URN idea, I see this as a serious
problem. I don't see #1 or #2 as proper solutions.  My inclination at this
point it to use #3.

Thoughts?

Dan

Re: [Scrollkeeper-devel] Better internationalization support

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

Dan Mueth wrote:
> 
> On Fri, 20 Apr 2001, Laszlo Kovacs wrote:
> 
> > So I thought maybe an OMF URN version field should be added, like:
> >
> > urn:x-omf:omf-urn-version:organization:group:name:version:language:format
> >
> > where omf-urn-version is for internal purpose to track changes in our
> > URN structure. Although we could also use x-omf1, x-omf2 etc instead of
> > x-omf. Do people think this would be useful?
> 
> So, we would have:
> 
> urn:x-omf1:organization:group:name:version:language:format
> 
> where organization will normally be a domain and group is whatever the
> coordinators for that domain choose (package, project, etc.)
> 
> The part of this which will be used to identify a series of a document
> (different versions, formats, and languages) is:
> 
> urn:x-omf1:organization:group:name
> 
> Note that this means that a document cannot be moved between organizations
> or groups or it will lose its "identity". (eg. an organization changes its
> name, a document changes groups such as by being moved into a different
> package, etc. ) The versions before the move will belong to a different
> series from those versions after the move.  Fundamentally, the part of the
> URN which describes the series should never change, even if the old labels
> no longer accurately describe the document, because this part of the URN
> is being used to identify the document series.
> 
> So, we have a few choices here:
> 
> 1) Use the URN's as if they are metadata and change the URN if the
> organization, doc name, or doc group changes.  This undermines the purpose
> of having a document series identifier.  We could do it anyway and just
> live with a certain level of breakage in the system, but this does not
> seem like The Right Way.
> 
> 2) Try to enforce that once the document series portion of the URN is set,
> it should not be changed.  This is the behavior one expects from a
> document series identifier.  However, it seems odd since the URN looks
> like metadata and people would not want "incorrect" metadata.  Plus, most
> people will probably not realize they should not change this part and
> change it anyway.
> 
> 3) Go back to using the uuidgen system (or some other system) for series
> id's.  Note that we may still use URN's for unique document identifiers.
> We would be going back to the original plan of having two identifiers: one
> for the doc series and one as a unique resource identifier.  If we do
> this, we would have to seperately evaluate whether URN's or uuidgen are
> better for the unique document identifiers.
> 
> 4) ???
> 
> Although I had really warmed up to the URN idea, I see this as a serious
> problem. I don't see #1 or #2 as proper solutions.  My inclination at this
> point it to use #3.
> 
> Thoughts?

Seems like a valid point, we should probably go with the uuidgen then. 

Laszlo

Re: [Scrollkeeper-devel] Better internationalization support

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

> From: Dan Mueth <da...@ea...>
>
> So, we would have:
> 
> urn:x-omf1:organization:group:name:version:language:format
> 
> where organization will normally be a domain and group is whatever the
> coordinators for that domain choose (package, project, etc.)

I seem to have missed the introduction of :group: in
the URN.  Is that necessary to establishing a document
"name" part?  Or is it part of the metadata (in which case
shouldn't it be in the OMF metadata elements)?
 
> The part of this which will be used to identify a series of a document
> (different versions, formats, and languages) is:
> 
> urn:x-omf1:organization:group:name
> 
> Note that this means that a document cannot be moved between organizations
> or groups or it will lose its "identity". (eg. an organization changes its
> name, a document changes groups such as by being moved into a different
> package, etc. ) The versions before the move will belong to a different
> series from those versions after the move.  Fundamentally, the part of the
> URN which describes the series should never change, even if the old labels
> no longer accurately describe the document, because this part of the URN
> is being used to identify the document series.
> 
> So, we have a few choices here:
> 
> 1) Use the URN's as if they are metadata and change the URN if the
> organization, doc name, or doc group changes.  This undermines the purpose
> of having a document series identifier.  We could do it anyway and just
> live with a certain level of breakage in the system, but this does not
> seem like The Right Way.  

I agree, changing the URN of a specific version of a
document is The Wrong Way.  The purpose of URNs is to
be a permanent name for a specific document.  If you start
changing them, we couldn't call them URNs.
 
> 2) Try to enforce that once the document series portion of the URN is set,
> it should not be changed.  This is the behavior one expects from a
> document series identifier.  However, it seems odd since the URN looks
> like metadata and people would not want "incorrect" metadata.  Plus, most
> people will probably not realize they should not change this part and
> change it anyway.

You are probably right.  The URN isn't metadata, it is a
pointer to a document and its associated metadata.
According the URN RFCs, the OMF would be the ultimate
authority of how this namespace is to be interpreted.  But
I could see how someone who doesn't refer to the namespace
definition could be confused when they don't match.
 
> 3) Go back to using the uuidgen system (or some other system) for series
> id's.  Note that we may still use URN's for unique document identifiers.
> We would be going back to the original plan of having two identifiers: one
> for the doc series and one as a unique resource identifier.  If we do
> this, we would have to seperately evaluate whether URN's or uuidgen are
> better for the unique document identifiers.

I agree.  I don't think the document ID should try to
carry a series ID.  The principle purpose of a document ID
is to uniquely and permanently identify a particular
document.  Trying to force it to also function as a series ID
leads to the contradictions that Dan points out.

Dan's option #3 would make a series ID into another piece of
information that is associated with a document. 
That frees the URN name to track the current
organization for each version.

But I'm not clear where a series ID fits into the OMF
metadata DTD.  If I understand you correctly, the same
series ID would be applied to every version/language/format
of a document in its history, including when it changes
hands.  But the OMF <identifier> element is supposed to be
unique to each document.

I would propose instead using the OMF <relation> element,
with its url attribute pointing to a series ID.  By that I
mean define a seriesID using uuidgen as Dan suggests.  Then
the OMF metadata for each document includes

<relation url="thisseriesUUID" status="omf-series-id"/>

This defines a relationship between this document and the
series of which it is a part.  Then you could query an OMF
metadata collection to select all documents that share the
same relation element.  From that you could select specific
alternate version/language/format documents.

Would this be a correct usage of the <relation> element?
Would it meet the needs of a seriesID?

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] Better internationalization support

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

Bob Stayton wrote:
> 
> > From: Dan Mueth <da...@ea...>
> >
> > So, we would have:
> >
> > urn:x-omf1:organization:group:name:version:language:format
> >
> > where organization will normally be a domain and group is whatever the
> > coordinators for that domain choose (package, project, etc.)
> 
> I seem to have missed the introduction of :group: in
> the URN.  Is that necessary to establishing a document
> "name" part?  Or is it part of the metadata (in which case
> shouldn't it be in the OMF metadata elements)?

Oh, this was me. I just thought that for a large organization we might
want to have another level between organization and document. Obvious
values for this are project or package name.

[snip]

> I would propose instead using the OMF <relation> element,
> with its url attribute pointing to a series ID.  By that I
> mean define a seriesID using uuidgen as Dan suggests.  Then
> the OMF metadata for each document includes
> 
> <relation url="thisseriesUUID" status="omf-series-id"/>
> 
> This defines a relationship between this document and the
> series of which it is a part.  Then you could query an OMF
> metadata collection to select all documents that share the
> same relation element.  From that you could select specific
> alternate version/language/format documents.
> 
> Would this be a correct usage of the <relation> element?
> Would it meet the needs of a seriesID?

I looked at the definition of the <relation> element and it didnt seem
very obvious if it is ok, but I think we could use it like the above.

Laszlo

Re: [Scrollkeeper-devel] Better internationalization support

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

> But I'm not clear where a series ID fits into the OMF
> metadata DTD.  If I understand you correctly, the same
> series ID would be applied to every version/language/format
> of a document in its history, including when it changes
> hands.  But the OMF <identifier> element is supposed to be
> unique to each document.

Right.  So I guess the URN would go in identifier.  This can be done
without any modification to the OMF I believe.  (Is a URN considered a
URL?  If not, I guess we should explicitly state that an identifier may be
a URN.)

eg:
<identifier>http://www.ldp.org/docs/howto/nfs</identifier>
<identifier>urn:blahblahblah</identifier>

If anybody replies to this, let's please start a new thread with a title
about URN's ;)

> I would propose instead using the OMF <relation> element,
> with its url attribute pointing to a series ID.  By that I
> mean define a seriesID using uuidgen as Dan suggests.  Then
> the OMF metadata for each document includes
> 
> <relation url="thisseriesUUID" status="omf-series-id"/>
> 
> This defines a relationship between this document and the
> series of which it is a part.  Then you could query an OMF
> metadata collection to select all documents that share the
> same relation element.  From that you could select specific
> alternate version/language/format documents.
> 
> Would this be a correct usage of the <relation> element?
> Would it meet the needs of a seriesID?

I think using a uuidgen code and putting it in RELATION is the way to
go.  (I was completely overlooking this element.)  I would propose
breaking RELATION into two attributes:  RELATION.identifier and
RELATION.seriesid.  The identifier attribute should follow the guidelines
of the IDENTIFIER element - it can point to any valid URL/URN.  The
seriesid is the document series id code, obtained from uuidgen.

It would look something like this:

-----
14.     Relation
        Label: RELATION
        Obligation: Optional
                RELATION.IDENTIFIER (Optional)
                RELATION.SERIESID (Optional)
        Maximum Occurrence: Repeatable

Description of the resource's relationship with other similar resources.  
RELATION.IDENTIFIER is a URL that points to the IDENTIFIER element of
another resource.  Each instance of RELATION with the RELATION.IDENTIFIER
attribute links the resource to other resources of similar domain or
style. RELATION.SERIESID is a string code which specifies various
instances of a document, such as various versions, formats, or
translations.  All documents which are related in these ways should have
the same RELATION.SERIESID.  No documents which do not belong to this
set should share the RELATION.SERIESID.
-----

I imagine somebody else on the list can write this more clearly.

BTW: Are any of the OMF maintainers on this list following this
thread?  It would be nice to hear your opinions.

Dan

Re: [Scrollkeeper-devel] Better internationalization support

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

On Wed, 18 Apr 2001, Bob Stayton wrote:

> I read the OMF element descriptions again and I think
> we need to be careful how we use the <identifier> element.
> According to the description, <identifier> is a URI
> that points to a unique document.  Since <identifier> is part
> of an OMF record, and since an OMF record also has
> elements for the document's language, version, and
> format, I interpret the <identifier> element to be
> a reference to one combination of
> document+language+version+format.  Each such combination
> would have its own OMF record.
> 
> But you would like to be able to use a fallback mechanism
> that permits providing access to alternate versions,
> languages, or formats, depending on the needs of the user,
> right?
> 
> A simple URN like <urn:kde:GetStart> is really an abstract
> reference to the collection of all combinations of
> language+version+format for the KDE getting started guide.
> If the identifier is in a parsible format, such as
> name+language+version+format, then it is unique and yet it
> can be picked apart as needed for fallback along
> any of the dimensions.  
> 
> Using a fixed field format:
> 
> <urn:kde:GetStart+en+3.1+pdf>
> 
> or maybe a more flexible URL syntax which identifies
> each field:
> 
> <urn:kde:GetStart?lang=en&version=3.1&format=pdf>

Everything you say seems right, and this approach should work. (Although I
think a couple small details of the syntax would have to be
changed: http://www.ietf.org/rfc/rfc2141.txt .)

This would solve a few problems at once - the unique id, the document set
id, and it would allow us to integrate with the URN resource location
system.

It seems somewhat complicated though and would be a substantial amount of
work to achieve.  We would have to go through the application and review
procedure to get our NID, which I'm guessing is enough trouble that few
people would want to get their own NID.  Then, we would have to actively
manage a pretty large set of NSS's.  This would probably only be tractable
if we had an automatic system to handle requests.

If we just wanted to solve the document set id problem, then using uuidgen
would be a much simpler solution, both as an organization and for
individuals.  So, whether we would use something like this largely comes
down to how important it is that we adopt the URN system for its own
value.  I don't know enough about the URN system to know how widely
adopted it is or what tools exist to take advantage of it.  Could you fill
us in here?  

Do DNS servers currently support URN's?

Note we could still use the URN system with uuidgen:

"urn:gnome.org:`uuidgen`"

which would remove most of the admin headache.  We would need a seperate
id using uuidgen for the document groups (all formats, locales, and
versions of a document).

Dan