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