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] 1/29/2003: Localization Capabilities

Understood.  I have been on a project that had to accommodate the
backend impacts you cite here (impacted by what database technology is
used there).

-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: Wednesday, January 29, 2003 10:15 AM
To: Monica Martin
Cc: Farrukh Najmi; Chiusano Joseph; Breininger Kathryn R; ebXML Regrep
(E-mail); sang.shin@sun.com; weida@apelon.com; akotok@disa.org
Subject: Re: [regrep] 1/29/2003: Localization Capabilities

One of the hardest issues is to cater to the storage of local registry 
objects.  THis requires that the localized DB back end (repository) must

be capable of supporting different character sets that go way beyond the

first 255 characters.  Advanced features like "sort" may run into 
problems if one has to determine the order or 2,000 japanese kanji 

Food for thought....


Monica Martin wrote:
> Thanks, Farrukh.  See inline with [mm1].
> -----Original Message-----
> From: Farrukh Najmi [mailto:farrukh.najmi@sun.com]
> Sent: Wednesday, January 29, 2003 9:41 AM
> To: Monica Martin
> Cc: Chiusano Joseph; Breininger Kathryn R; ebXML Regrep (E-mail);
> sang.shin@sun.com; weida@apelon.com; akotok@disa.org;
> Subject: Re: [regrep] 1/29/2003: Localization Capabilities
> Monica Martin wrote:
>>We indicated to the party raising the question, that we had the
>>Localized capability.  This was raised particularly by some of the
> teams
>>that are very multi-lingual focused, such as Dublin Core Registry
>>prototype (They have to accommodate more than 20 languages).  I noted
> in
>>ebRS that we briefly discuss in section G.4.2:
>>However, the language information may be used as one of the query
>>criteria, such as retrieving only DTD written in French. 
> This is currently supported by our ad hoc query mechanisms. A DTD may
> classified by a language classification and then an ad hoc query may 
> find DTDs classified by the French language classification.
> mm1: Would it good to ensure that the further definition is included
> that section or as an example for ad hoc query (if not otherwise
> handled)?  My suggestion is yes.
>>Furthermore, a
>>language negotiation procedure, like registry client is asking a
>>favorite language for messages from registry services, could be
>>functionality for the future revision of this document.
> Above type of functionality may be more sensible to leave to client
> rather than registry specs. JAXR API for example allows clients to 
> specify their preferred language and get localized content
> using the API. This is possible in JAXR even today with our current
> specs.
> Of course we would be open to a clearly articulated use case and need 
> for additional spec functionality in this area.
>>Perhaps extended query or other important localization needs can be
>>addressed in the future.  Thoughts?
> Again we would need to see clear use cases and need justification. I
> not believe that we have that in this thread.
> mm1: This was not a proposal to do so, just a question.  I understand
> the fine line regarding what is specification or implementation
> specific.  Again, suggest we provide some clarification in that
> regarding the 'fine line.'
> Thank you.
> Monica
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

VP Strategic Relations,
Technologies Evangelist
XML Global Technologies
ebXML software downloads - http://www.xmlglobal.com/prod/

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

Powered by eList eXpress LLC