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


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; lane.derek@epa.gov
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 be

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 in
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 another
>functionality for the future revision of this document.
>
Above type of functionality may be more sensible to leave to client APIs

rather than registry specs. JAXR API for example allows clients to 
specify their preferred language and get localized content appropriately

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 do 
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 section
regarding the 'fine line.'

Thank you.
Monica


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


Powered by eList eXpress LLC