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...