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