[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