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