OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [regrep] I18N bug fix proposal


reply:
While I certainly agree that allowing this "multiple description and name"
capability is a good thing, I do not classify this as a "bug fix."  This is
clearly an enhancement and should be characterized and prioritized as such.
Joel

-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
Sent: Thursday, November 08, 2001 9:12 AM
To: regrep@lists.oasis-open.org
Subject: [regrep] I18N bug fix proposal


Team,

I have come to realize that we have a major bug in our I18N solution.
Since the purpose of V2.0 is to address major bugs I would like to
propose that we fix this bug for V2.0. Some background follows:


The Perceived Problem
------------------------
Sections F.3 and F.4 in RS 1.0 imply that a RegistryEntry and a
RepositoryItem are associated with exactly 1 Locale. This implies that
if an SO wishes to submit the same RegsitryObject in multiple locales
they have to submit multiple localized copies of the object each with
its own different identifier. This creates problems when wanting to
reference the RegistryObject. The referee has to decide which localized
version of the object to refer to.

To summarize our current I18N model implies that to localize a
RegistryObject an SO has to submit multiple RegistryObjects where each
of the copies are identical as far as non-localized attributes are
concerned (the majority of attributes) and only differ in a few
localized attributes such as name and description on RegistryObject.

The Alternative
---------------
The alternative that addresses the above problem is where there is a
single RegistryObject that serves all locales. Where ever, it has an
I18N capable attribute (e.g. RegistryObject's name and description) it
uses a Collection of localized String rather than a single String
attribute. The result is that a single RegistryObject contains all the
non-I18N capable attributes as well as all the localized version of I18N
capable attributes.

A Proposed Solution
---------------------
I have recently had to fix this problem in the JAXR API and believe that
we can apply the same fix to OASIS ebXML Registry. The solution defines
two new classes in the model:

Class InternationalString
-------------------------
This class is used as a replacement for the String type whenever a
String attribute needs to be I18N capable (e.g. RegistryObjects name and
description). An instance of the InternationalString interface composes
within it a Collection of LocalizedString instances, where each String
is specific to a particular Locale. The InternationalString has a single
Collection attribute of type LocalizedString.

Class LocalizedString
----------------------
This class is used as a simple wrapper class that relates a String with
its locale. This class is needed in the InternationalString interface
where a Collection of LocalizedString instances are kept. The
LocalizedString class defines 3 attributes:

- value : String This attribute defines the locale specific String

-character set: The character set used by the String

-language: The language as defined by xml:lang in

Lisa has agreed to allow discussion on this issue in today's meeting.
Please read this email in preparation.

--
Regards,
Farrukh



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC