> Yes but Java has it's own limitations, performance is still it's weakest 
> link. I've used a Java based IDE called Eclipse and it's unacceptably 
> slow on my Pentium 450. Since the primary role of this interface is 
> filtering and parsing I'd hate to see it bogged down by the overhead of 
> a completely Java implementation.

> >
> >On Fri, 2002-01-18 at 13:09, Yves Savourel wrote:
> >
> >>>Most interesting Yves - I've read through the Okapi docs and it sounds
> >>>like a great project. Have you given any thought towards a Java-based
> >>>version ?
> >>>
> John
> 
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

BNF for PropsFileParser.jj

NON-TERMINALS

Hi All,

>The COM implementation of the Okapi API interface wouldn't be
>transportable but the underlying Filters are pure C++ which isn't tied
>to Win32 in anyway. So porting the filters to other platforms in shared
>libraries and using the Java based Okapi API interface would still be
>possible right using JNI ?? Scenario: Java localization client
>calls/uses Java Okapi interface which invokes via JNI a shared library
>of various filters. This is done in various forms for GUI's currently
>isn't it.

I would agree with this. We develop some cross-platform software and we use
C/C++ to write the main code. Once this is done, we can then wrap this code
in a COM/Java wrapper as necessary. It also gives us the opportunity to use
other protocols such as SOAP if we need to ...

David Pooley
Software Architect
SDL International


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept
for the presence of computer viruses.

**********************************************************************

Hello Tim,

>Message: 1
>   Date: 18 Jan 2002 14:43:25 +0000
>   From: Tim Foster <tim.foster@...>
>Subject: RE: Localization Directives - Working Example
>
>Hi Yves,
>
>Yep - JNI could help a little, but you'd still be tied you to whatever
>architecture the COM components are compiled for (win32 - right ?) JNI
>provides hooks into a shared object. However, in order that to use a
>tool across platforms with JNI, you need to recompile the shared object
>(and the hooks) for each architecture you're deploying to.
>
The COM implementation of the Okapi API interface wouldn't be
transportable but the underlying Filters are pure C++ which isn't tied
to Win32 in anyway. So porting the filters to other platforms in shared
libraries and using the Java based Okapi API interface would still be
possible right using JNI ?? Scenario: Java localization client
calls/uses Java Okapi interface which invokes via JNI a shared library
of various filters. This is done in various forms for GUI's currently
isn't it.

>
>A pure Java implementations would mean that Okapi could scale all the
>way from single processor destops to 106-cpu servers, which isn't the
>case at the moment (since I can't compile win32 libraries on a sparc
>:-).
>
>
Yes but Java has it's own limitations, performance is still it's weakest
link. I've used a Java based IDE called Eclipse and it's unacceptably
slow on my Pentium 450. Since the primary role of this interface is
filtering and parsing I'd hate to see it bogged down by the overhead of
a completely Java implementation.

>
>On Fri, 2002-01-18 at 13:09, Yves Savourel wrote:
>
>>>Most interesting Yves - I've read through the Okapi docs and it sounds
>>>like a great project. Have you given any thought towards a Java-based
>>>version ?
>>>
John

Hi Yves,

Yep - JNI could help a little, but you'd still be tied you to whatever
architecture the COM components are compiled for (win32 - right ?) JNI
provides hooks into a shared object. However, in order that to use a
tool across platforms with JNI, you need to recompile the shared object
(and the hooks) for each architecture you're deploying to.

A pure Java implementations would mean that Okapi could scale all the
way from single processor destops to 106-cpu servers, which isn't the
case at the moment (since I can't compile win32 libraries on a sparc
:-).

	 cheers,
			 tim


On Fri, 2002-01-18 at 13:09, Yves Savourel wrote:
> > Most interesting Yves - I've read through the Okapi docs and it sounds
> > like a great project. Have you given any thought towards a Java-based
> > version ?
>
> Hi Tim,
>
> Definitely: the aim is to define generic interfaces that could be
> implemented in any language capable of implementing such interface. Just
> like SAX and DOM interfaces are implemented in various languages.
> We should also be able to have some intermediate layer that would allow COM
> filters to be called from Java and Java filters to be called from COM. I'm
> not very knowledgeable in those areas but assume JNI would help there.
>
> -ys
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

> Most interesting Yves - I've read through the Okapi docs and it sounds
> like a great project. Have you given any thought towards a Java-based
> version ?

Hi Tim,

Definitely: the aim is to define generic interfaces that could be
implemented in any language capable of implementing such interface. Just
like SAX and DOM interfaces are implemented in various languages.
We should also be able to have some intermediate layer that would allow COM
filters to be called from Java and Java filters to be called from COM. I'm
not very knowledgeable in those areas but assume JNI would help there.

-ys

Hi there,

Most interesting Yves - I've read through the Okapi docs and it sounds
like a great project. Have you given any thought towards a Java-based
version ?

	 cheers,
			 tim


On Thu, 2002-01-17 at 21:59, Yves Savourel wrote:
> > Yves, this message came through empty at my end. Did anyone
> > else get content? (new exercise in content mismanagement?)
> > Bye, Sue Ellen
>
> Hi Sue Ellen,
>
> It came through correctly to me and it looks fine on the Group page.
> (http://groups.yahoo.com/group/lisa-its/message/139)
>
> Maybe some unfriendly filtering feature somewhere in the path between Yahoo
> and your mailbox caused this?
>
> Here is it again for you:
> -ys
>
>
> ------------------------------
> Hello,
>
> One of the possible output of ITS is the definition of localization
> directives as a specific XML namespace, so any XML document can safely be
> marked up for localization-specific information.
>
> An example of such directives, but in this case apply to non-XML files, is
> now available through one of the Okapi Framework components posted today.
> The Java Properties filter supports a start of directives: text to translate
> or not-translate, localization-specific notes. Although this is not an XML
> example, it may help to understand better how such mechanism could work in
> XML as well.
>
> The Okapi Framework is a set of components, guidelines, APIs, and other
> elements that provide ways to make the different steps of the translation
> and localization process more interoperable. Several items have been made
> public today:
>
>
> 1) The Filter Interface specifications (draft):
> http://okapi.sourceforge.net/interface_filter.html
>
> One of the most used type of components in localization are filters. In
> order to use filters from different tools, you need a standard interface.
> There is no such standard today, when/if one is created Okapi filters will
> support it, meanwhile Okapi filters use its own interface. The early draft
> for this interface is now available.
> In addition to offer extraction and merging to and from XLIFF, the interface
> provides a set of low-level methods to access the filtered input at the
> 'item' level, allowing to write in a few lines of code utilities that can
> read and write files modifying just what you want.
>
>
> 2) The Localization Directives specifications (draft):
> http://okapi.sourceforge.net/format_locdir.html
>
> Including localization-specific information within your source files can
> provide a great way to communicate efficiently information from the
> developer or author to the localizers. To take full advantage of such
> mechanism, a simple standard way of doing it will allow any
> localization/translation tool to take advantage of such embedded comments.
> There are no such standard today, when/if one is created Okapi tools will
> support it, meanwhile the Localization Directives format is the way Okapi
> filters implement such annotations.
>
>
> 3) The Java Properties Filter:
> http://okapi.sourceforge.net/javapropertiesfilter.html
>
> This component is a COM object implementing the Okapi Filter Interface for
> Java Properties files. It also supports the Okapi Localization Directives.
> You can use it from traditional C++ applications, or from any other
> COM-enabled applications. It comes with an example of use in C++ and in
> Excel VBA.
>
>
> 4) The OkapiBase Library (preliminary):
> http://okapi.sourceforge.net/OkapiBase/index.html
>
> This library implements various classes designed for
> localization/translation tools. It includes classes and functions to deal
> with encoding, localization directives, XLIFF reader and writer, and so
> forth.
>
>
> 5) The OkapiFilters Library (preliminary):
> http://okapi.sourceforge.net/OkapiBase/index.html
>
> This library implements a set of base classes designed to help in developing
> parsers and filters. This library aims at helping you create filters
> compatible with the Okapi Filter Interface.
>
>
> All Okapi components are open-source and free. Other Okapi components and
> specifications are under development, for more information see
> http://okapi.sourceforge.net.
>
> Regards,
> -yves
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Hi all,

the same thing happened to me as to Sue Ellen, so the problem isn't unique
to her machine or service.

-Arle

On 1/17/02 17:52, "sewright" <sewright@...> wrote:

> Thanks indeed! This is relevant to several discussions I'm involved in. No
> idea why it got scalped in transmission -- I rarely have such episodes in
> this particular mail service.
> Bye for now,
> Sue Ellen

Thanks indeed! This is relevant to several discussions I'm involved in. No
idea why it got scalped in transmission -- I rarely have such episodes in
this particular mail service.
Bye for now,
  Sue Ellen
----- Original Message -----
From: "Yves Savourel" <yves@...>
To: <lisa-its@yahoogroups.com>
Sent: Thursday, January 17, 2002 4:59 PM
Subject: RE: [lisa-its] Localization Directives - Working Example


> > Yves, this message came through empty at my end. Did anyone
> > else get content? (new exercise in content mismanagement?)
> > Bye, Sue Ellen
>
> Hi Sue Ellen,
>
> It came through correctly to me and it looks fine on the Group page.
> (http://groups.yahoo.com/group/lisa-its/message/139)
>
> Maybe some unfriendly filtering feature somewhere in the path between
Yahoo
> and your mailbox caused this?
>
> Here is it again for you:
> -ys
>
>
> ------------------------------
> Hello,
>
> One of the possible output of ITS is the definition of localization
> directives as a specific XML namespace, so any XML document can safely be
> marked up for localization-specific information.
>
> An example of such directives, but in this case apply to non-XML files, is
> now available through one of the Okapi Framework components posted today.
> The Java Properties filter supports a start of directives: text to
translate
> or not-translate, localization-specific notes. Although this is not an XML
> example, it may help to understand better how such mechanism could work in
> XML as well.
>
> The Okapi Framework is a set of components, guidelines, APIs, and other
> elements that provide ways to make the different steps of the translation
> and localization process more interoperable. Several items have been made
> public today:
>
>
> 1) The Filter Interface specifications (draft):
> http://okapi.sourceforge.net/interface_filter.html
>
> One of the most used type of components in localization are filters. In
> order to use filters from different tools, you need a standard interface.
> There is no such standard today, when/if one is created Okapi filters will
> support it, meanwhile Okapi filters use its own interface. The early draft
> for this interface is now available.
> In addition to offer extraction and merging to and from XLIFF, the
interface
> provides a set of low-level methods to access the filtered input at the
> 'item' level, allowing to write in a few lines of code utilities that can
> read and write files modifying just what you want.
>
>
> 2) The Localization Directives specifications (draft):
> http://okapi.sourceforge.net/format_locdir.html
>
> Including localization-specific information within your source files can
> provide a great way to communicate efficiently information from the
> developer or author to the localizers. To take full advantage of such
> mechanism, a simple standard way of doing it will allow any
> localization/translation tool to take advantage of such embedded comments.
> There are no such standard today, when/if one is created Okapi tools will
> support it, meanwhile the Localization Directives format is the way Okapi
> filters implement such annotations.
>
>
> 3) The Java Properties Filter:
> http://okapi.sourceforge.net/javapropertiesfilter.html
>
> This component is a COM object implementing the Okapi Filter Interface for
> Java Properties files. It also supports the Okapi Localization Directives.
> You can use it from traditional C++ applications, or from any other
> COM-enabled applications. It comes with an example of use in C++ and in
> Excel VBA.
>
>
> 4) The OkapiBase Library (preliminary):
> http://okapi.sourceforge.net/OkapiBase/index.html
>
> This library implements various classes designed for
> localization/translation tools. It includes classes and functions to deal
> with encoding, localization directives, XLIFF reader and writer, and so
> forth.
>
>
> 5) The OkapiFilters Library (preliminary):
> http://okapi.sourceforge.net/OkapiBase/index.html
>
> This library implements a set of base classes designed to help in
developing
> parsers and filters. This library aims at helping you create filters
> compatible with the Okapi Filter Interface.
>
>
> All Okapi components are open-source and free. Other Okapi components and
> specifications are under development, for more information see
> http://okapi.sourceforge.net.
>
> Regards,
> -yves
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

> Yves, this message came through empty at my end. Did anyone
> else get content? (new exercise in content mismanagement?)
> Bye, Sue Ellen

Hi Sue Ellen,

It came through correctly to me and it looks fine on the Group page.
(http://groups.yahoo.com/group/lisa-its/message/139)

Maybe some unfriendly filtering feature somewhere in the path between Yahoo
and your mailbox caused this?

Here is it again for you:
-ys


------------------------------
Hello,

One of the possible output of ITS is the definition of localization
directives as a specific XML namespace, so any XML document can safely be
marked up for localization-specific information.

An example of such directives, but in this case apply to non-XML files, is
now available through one of the Okapi Framework components posted today.
The Java Properties filter supports a start of directives: text to translate
or not-translate, localization-specific notes. Although this is not an XML
example, it may help to understand better how such mechanism could work in
XML as well.

The Okapi Framework is a set of components, guidelines, APIs, and other
elements that provide ways to make the different steps of the translation
and localization process more interoperable. Several items have been made
public today:


1) The Filter Interface specifications (draft):
http://okapi.sourceforge.net/interface_filter.html

One of the most used type of components in localization are filters. In
order to use filters from different tools, you need a standard interface.
There is no such standard today, when/if one is created Okapi filters will
support it, meanwhile Okapi filters use its own interface. The early draft
for this interface is now available.
In addition to offer extraction and merging to and from XLIFF, the interface
provides a set of low-level methods to access the filtered input at the
'item' level, allowing to write in a few lines of code utilities that can
read and write files modifying just what you want.


2) The Localization Directives specifications (draft):
http://okapi.sourceforge.net/format_locdir.html

Including localization-specific information within your source files can
provide a great way to communicate efficiently information from the
developer or author to the localizers. To take full advantage of such
mechanism, a simple standard way of doing it will allow any
localization/translation tool to take advantage of such embedded comments.
There are no such standard today, when/if one is created Okapi tools will
support it, meanwhile the Localization Directives format is the way Okapi
filters implement such annotations.


3) The Java Properties Filter:
http://okapi.sourceforge.net/javapropertiesfilter.html

This component is a COM object implementing the Okapi Filter Interface for
Java Properties files. It also supports the Okapi Localization Directives.
You can use it from traditional C++ applications, or from any other
COM-enabled applications. It comes with an example of use in C++ and in
Excel VBA.


4) The OkapiBase Library (preliminary):
http://okapi.sourceforge.net/OkapiBase/index.html

This library implements various classes designed for
localization/translation tools. It includes classes and functions to deal
with encoding, localization directives, XLIFF reader and writer, and so
forth.


5) The OkapiFilters Library (preliminary):
http://okapi.sourceforge.net/OkapiBase/index.html

This library implements a set of base classes designed to help in developing
parsers and filters. This library aims at helping you create filters
compatible with the Okapi Filter Interface.


All Okapi components are open-source and free. Other Okapi components and
specifications are under development, for more information see
http://okapi.sourceforge.net.

Regards,
-yves

Yves, this message came through empty at my end. Did anyone else get
content? (new exercise in content mismanagement?)
Bye, Sue Ellen
----- Original Message -----
From: "Yves Savourel" <yves@...>
To: <lisa-its@yahoogroups.com>
Sent: Thursday, January 17, 2002 4:15 PM
Subject: [lisa-its] Localization Directives - Working Example


>

Hello,

One of the possible output of ITS is the definition of localization
directives as a specific XML namespace, so any XML document can safely be
marked up for localization-specific information.

An example of such directives, but in this case apply to non-XML files, is
now available through one of the Okapi Framework components posted today.
The Java Properties filter supports a start of directives: text to translate
or not-translate, localization-specific notes. Although this is not an XML
example, it may help to understand better how such mechanism could work in
XML as well.

The Okapi Framework is a set of components, guidelines, APIs, and other
elements that provide ways to make the different steps of the translation
and localization process more interoperable. Several items have been made
public today:


1) The Filter Interface specifications (draft):
http://okapi.sourceforge.net/interface_filter.html

One of the most used type of components in localization are filters. In
order to use filters from different tools, you need a standard interface.
There is no such standard today, when/if one is created Okapi filters will
support it, meanwhile Okapi filters use its own interface. The early draft
for this interface is now available.
In addition to offer extraction and merging to and from XLIFF, the interface
provides a set of low-level methods to access the filtered input at the
'item' level, allowing to write in a few lines of code utilities that can
read and write files modifying just what you want.


2) The Localization Directives specifications (draft):
http://okapi.sourceforge.net/format_locdir.html

Including localization-specific information within your source files can
provide a great way to communicate efficiently information from the
developer or author to the localizers. To take full advantage of such
mechanism, a simple standard way of doing it will allow any
localization/translation tool to take advantage of such embedded comments.
There are no such standard today, when/if one is created Okapi tools will
support it, meanwhile the Localization Directives format is the way Okapi
filters implement such annotations.


3) The Java Properties Filter:
http://okapi.sourceforge.net/javapropertiesfilter.html

This component is a COM object implementing the Okapi Filter Interface for
Java Properties files. It also supports the Okapi Localization Directives.
You can use it from traditional C++ applications, or from any other
COM-enabled applications. It comes with an example of use in C++ and in
Excel VBA.


4) The OkapiBase Library (preliminary):
http://okapi.sourceforge.net/OkapiBaseDoc/index.html

This library implements various classes designed for
localization/translation tools. It includes classes and functions to deal
with encoding, localization directives, XLIFF reader and writer, and so
forth.


5) The OkapiFilters Library (preliminary):
http://okapi.sourceforge.net/OkapiBaseDoc/index.html

This library implements a set of base classes designed to help in developing
parsers and filters. This library aims at helping you create filters
compatible with the Okapi Filter Interface.


All Okapi components are open-source and free. Other Okapi components and
specifications are under development, for more information see
http://okapi.sourceforge.net.

Regards,
-yves

FYI:

XLIFF, the XML Localisation Interchange File Format (which has several
aspects also related to ITS), is moved under the eagis of OASIS.

-ys


-----Original Message-----
Sent: Mon, December 17, 2001 7:28 AM

A new OASIS technical committee is being formed. The OASIS XML
Localisation Interchange File Format Technical Committee has been
proposed by the following members of OASIS: Tony Jewtushenko, Oracle;
Matthew Lovatt, Oracle; Fiona Ebbs, Novell; John Reid, Novell; John
Corrigan, Sun Microsystems; Mark Levins, IBM/Lotus; Yves Savourel, RWS
Group; Enda McDonnell, Individual member; Jonathan Clark, Lionbridge;
Milan Karasek, Moravia; and Peter Reynolds, Individual member.

The proposal for a new TC meets the requirements of the OASIS TC Process
(see http://oasis-open.org/committees/process.shtml), and is appended to
this message. The proposal, which includes a statement of purpose, list
of deliverables, and proposed schedule, will constitute the TC's
charter. The TC Process allows these items to be clarified (revised) by
the TC members; such clarifications (revisions), as well as submissions
of technology for consideration by the TC and the beginning of technical
discussions, may occur no sooner than the TC's first meeting.

To become a member of this new TC you must 1) be an employee of an OASIS
member organization or an Individual member of OASIS; 2) notify the TC
chair, Tony Jewtushenko (tony.jewtushenko@...), of your intent to
participate at least 15 days prior to the first meeting; and 3)
participate in the first meeting on 22 January 2002. You should also
subscribe to the TC's discussion list. Note that membership in OASIS TCs
is by individual, and not by organization. You must be eligible for
participation at the time you time you notify the chair.

The private mail list xliff@... is for committee
discussions. TC members as well as any other interested OASIS members
should subscribe to the list by going to the mail list web page at
http://lists.oasis-open.org/ob/adm.pl, or by sending a message to
xliff-request@... with the word "subscribe" as the body
of the message. (Note that subscribing to the mail list does not make
you a member of the TC; to become a member you must contact the TC chair
as described in the preceeding paragraph.)

A public comment list xliff-comment@... will be
available for the public to make comments on the work of this TC; the
public may subscribe to this list by going to the mail list web page at
http://lists.oasis-open.org/ob/adm.pl, or by sending a message to
xliff-comment-request@... with the word "subscribe" as
the body of the message.

The archives of both of these mail lists are visible to the public at
http://lists.oasis-open.org/archives/

</karl>
=================================================================
Karl F. Best
OASIS - Director, Technical Operations
978.667.5115 x206
karl.best@...  http://www.oasis-open.org



XLIFF Technical Committee Proposal

(i) Name of the TC:

     XLIFF, XML Localisation Interchange File Format

(ii) Statement of purpose:

     The purpose of the XLIFF TC is to define a specification for
     an extensible localisation interchange format that will allow
     any software provider to produce a single interchange format
     that can be delivered to and understood by any localisation
     service provider. The format should be tool independent,
     standardised, and support the whole localisation process.
     It will comprehensively support common software data
     formats and be open enough to allow the development of
     tools compatible with an implementer's own proprietary data
     formats and company culture.

     The current state of affairs in software localisation is
     that a software provider delivers their localisable
     resources to a localisation service provider in a number of
     disparate file formats. If the software provider has common
     industry standard file formats, this makes the task of
     interchanging files easier. However, when there are
     uncommon or nonstandard file formats either the software
     provider or the localisation service provider must provide
     a method for the file to be localised. For a software
     provider with many of these uncommon or nonstandard files,
     this requirement becomes a major hurdle when attempting to
     have their software localised.

     The first phase is to create a working specification that will
     concentrate on the software UI file requirements. However, it
     should also include all of the building blocks required to
     ensure that we could implement the document elements at any
     time.

     This work is based on work previously done by the Yahoo!
     DataDefinition Group. That group has produced a white
     paper, a specification, and a DTD, which were made public
     through that group's site. This specification will be
     submitted for approval as the XLIFF 1.0 specification in
     the first meeting.

     XLIFF 1.0 is submitted with the following intellectual
     property rights statement:

     Each of the submitting companies, referenced in section (vii),
     below, agrees to offer a license, on reasonable and non-
     discriminatory terms, to use any patent claim it owns or
     controls and which is necessarily infringed by use of the XLIFF
     format described in  this submission or any Committee
     Specification or OASIS standard based thereon. Such a license
     will be for the limited purpose of implementing the XLIFF format
     described in this submission or in any Committee Specification
     or OASIS standard based thereon, and may be conditioned on the
     licensee's agreement to grant a reciprocal license on reasonable
     and non-discriminatory terms to use any patent claim it owns or
     controls and which is necessarily infringed by use of the XLIFF
     format described in this submission or in any Committee
     Specification or OASIS standard based thereon.

     The archive for previous discussions can be found at the
     following URL:

     http://groups.yahoo.com/group/DataDefinition

     The white paper, the specification, and the DTD and can be
     found at this URL:

     http://groups.yahoo.com/group/DataDefinition/files/Final


(iii) Proposed list of deliverables, with projected dates:

     XLIFF 1.0 Specification; 2 weeks after 1st meeting
     XLIFF 1.0 DTD;           2 weeks after 1st meeting
     XLIFF 1.0 White Paper;   2 weeks after 1st meeting
     XLIFF 1.0 Schema;        2 months after 1st meeting
     XLIFF 1.1 Specification; 6 months after 1st meeting
     XLIFF 1.1 DTD;           6 months after 1st meeting
     XLIFF 1.1 Schema;        6 months after 1st meeting

(iv) Language in which the TC will conduct business:

     U.K. English

(v) Date and time of the first meeting:

     22 January 2002; 16:00 GMT; Phone conference

(vi) Meeting schedule for the year following the formation of the
     TC, or until the projected date of the final deliverable,
     whichever comes first:

     Bi-weekly phone conference

(vii) Names, electronic mail addresses, and membership affiliations
     of PEOTCPs committed to the stated meeting schedule:

     Tony Jewtushenko, tony.jewtushenko@...; Oracle
     Matthew Lovatt, matthew.lovatt@...; Oracle
     Fiona Ebbs; FEbbs@...; Novell
     John Reid; jreid@...; Novell
     John Corrigan, John.Corrigan@...; Sun Microsystems
     Mark Levins, Mark_Levins@...; IBM/Lotus
     Yves Savourel, ysavourel@...; RWS Group
     Enda McDonnell, EndaMcD@..., Individual member
     Jonathan Clark, Jonathan_Clark@..., Lionbridge
     Milan Karasek, milank@..., Moravia
     Peter Reynolds, Peter.Reynolds@..., Individual member

(viii) Name of the TC chair:

     Tony Jewtushenko, Oracle

(ix) Names of phone meeting sponsors:

     Tony Jewtushenko, Oracle

(x) Names of face-to-face meeting sponsors:

     Fiona Ebbs, Novell

Does anyone know of any good tools that can generate an XML based on
a DTD in Java?  Looking to dynamically place content in any type of
XML format.

Thanks,
Phil

Does anyone know of any good tools that can generate an XML based on
a DTD in Java?  Looking to dynamically place content in any type of
XML format.

Thanks,
Phil

Hi Gustavo,

You're right: not many things have happened since a while.
The main reason is that ITS and the related efforts do not have a 'legal
umbrella' yet. For people to contribute to some common pool of knowledge or
share developments, you need some basic framework in which to work. It's
important to make sure any contribution is accessible to all and stay
accessible later on. That all IP issues are resolved and contributions are
made in a clear framework.

The first effort of using OSCAR as the 'umbrella' was slow to develop and
bogged down since OSCAR wasn't made to host such thing initially. The OSCAR
goals and policy is currently being revised to allow initiative such as ITS
(and others) to truly exist. There is actually a meeting in Vienna (this
week I think) about this. I really hope progress can be made and the new
bylaws enacted at some point in the future.
If ultimately OSCAR is not able, for a reason or another, to host ITS, then
we have the option to look for example at OASIS or other entities, but here
again, it takes time to set those things in place.

I hope we'll find an official 'home' soon. Once this is done, I hope we will
have more contributions and we will be able to move forward quickly. As the
previous email mentioned, LionBridge just put its localization suite
ForeignDesk on the public domain as open source software, this is one more
sign showing that common contribution in our industry is making progress. A
common framework would bring a lot of benefits to commercial, in-house, and
open-source tools. ITS is just a small part of this.

best,
-yves



-----Original Message-----
From: g_hartmann2001@... [mailto:g_hartmann2001@...]
Sent: Mon, November 05, 2001 10:32 AM
To: lisa-its@yahoogroups.com
Subject: [lisa-its] Current status


Hello all,

     I haven't seen any discussions on the ITS group and I wonder,
what's the current status of proposal ? Is there anything being
developed at all ?
     It looks like nobody is willing to contribute with something but
Yves and Robert. Am I missing something here ?

bye,
     Gustavo.







Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Hi group.

Just received an email with regard to a tool that many may be
familiar with ForeignDesk.  (Originated with International
Communications - now part of Lionbridge)  Deals with TMX 1.3 (Level
1) in the beta.

I just thought it was interesting that it was released to the
OpenSource Community.

If you are interested - http://www.ForeignDesk.net.

>     It looks like nobody is willing to contribute with something
but
> Yves and Robert.

Sorry, I meant Richard, not Robert.

Gustavo.

Hello all,

     I haven't seen any discussions on the ITS group and I wonder,
what's the current status of proposal ? Is there anything being
developed at all ?
     It looks like nobody is willing to contribute with something but
Yves and Robert. Am I missing something here ?

bye,
     Gustavo.

you wrote :
> I would also like to add that Brazil is an amazing country.  I've
> only been once (Iguazu), but I enjoy South America.

Thanks :-) Hope we can exchange information and maybe some cultural
experience too !
I'm studying TMX and XLIFF too, but I'm still in a preliminary
stage...

Keep in touch,

bye,

Gustavo.

I have recently ordered the Savourel book due to my interest in i18n
XML issues.  I am currently researching xliff, and the tmx format.
So far I've had more success with researching tmx, as maintaining the
xliff DTD is pending on my acceptance to the user group.  So far,
I've managed to gather that xliff is purely for transporting
translation data around, and TMX is used for transporting translation
data and TM data around.  It is not yet apparent why there should be
2 formats, but maybe more study will reveal this.

Currently I have no idea who is using xliff, but I know that Trados
is using TMX.

I would also like to add that Brazil is an amazing country.  I've
only been once (Iguazu), but I enjoy South America.

Philip Starner
Lingoport, Inc.

Hello,

      First, I would like to introduce myself : my name is Gustavo
Hartmann and I´m  a Computer Science student from Brazil. I´ve been a
software developer for almost 8 years now, with focus on client-
server development.
      My most recent project is about creating a generic i18n tag
library in XML to be used with any XML vocabulary. So I felt that we
could work together and share some valuable information about the
subject.
      That´s all for now. I´m browsing the archive to catch up with
the members, I´ll soon be able to contribute and participate in the
discussions.
      I would like to congratulate Yves Savourel for his excellent
work on his book on i18n and l10n. It´s been a very inspiring reading
to me.


      Best regards,

     Gustavo Hartmann

Hello all,
   I have just become a member of this group, and I would like to say hello.
The reason that I have done so is that I have been an I18n
engineer/consultant for roughly one year.  I am currently consulting with a
Colorado based company named Lingoport, Inc.  I have been pooring through
the archives, and hope to become useful in the discussions once I come up to
speed.

Thank you,
Philip Starner

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the lisa-its
group.

   File        : /XMLWhizTrial.zip
   Uploaded by : whizlabs@...
   Description : XML@Whiz -  XML Tutorial and IBM XML Certification Test
Simulator. It consists of  4 Mock Tests (296 Questions) on the pattern of XML
Certification and an Interactive Quiz (60 Questions). The salient features
include High Level of Customization, Detailed Explanation, Quick Revision Tips, 
scorer of the month and many more. For detailed info: 
http://www.whizlabs.com/products/xmlwhiz/xmlwhiz.html

You can access this file at the URL

http://groups.yahoo.com/group/lisa-its/files/XMLWhizTrial.zip

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

whizlabs@...

Hi all,

sorry to do more cross posting on these lists, but here is some more
information on the RAND issue and why it is important. I have written an
article that outlines six arguments against RAND that the W3C response to
public criticism has to deal with before any such policy could be
implemented. The article is at:

http://www.lisa.org/2001/rand/rand.html

So please, if the issue seems important to any of you and you want to know
more, visit my article. It has links to a number of other sources (both pro
and con) and I have tried to boil the vast amount of public comment down to
what they key issues are.

(The reason I have posted off-topic posts concerning RAND on the SALT, OSCAR
and ITS lists is that in each group we are dedicated to the principle of
royalty-free standards, with no fees for anything we develop. In the case of
SALT in particular this is an attribute that was unusual for EU-funded
materials. Because we are dedicated to an RF model, the move by the W3C to
RAND is a negative precedent and should be at least debated before any
action can be taken. Good, intelligent criticism is what is needed, and what
list members here can provide.)

Thanks,

Arle

October 5, 2001 (11:48 A.M. Central Standard Time)

Hi all,

in case you haven't heard there is quite a flap right now over a policy
change that the W3C is trying to implement that would allow W3C members with
(software) patents on materials used in W3C standards to start charging
"Reasonable And Non-Discriminatory" (RAND) licensing fees for implementation
of W3C standards. Up till now the W3C has functioned under a royalty-free
(RF) model, much like the OSCAR and SALT groups have.

The proposed policy change was opened for public comment In August, but no
one seemed to have noticed it until September 29, when word got out.
Reaction to the policy since then has been very vocal and intense. (The
original close date for public comment was September 30, but public pressure
forced its extension until October 11).

The main focus of concern is that the proposed policy would effectively shut
the door on free and open-source software since any RAND licensing fee would
be discriminatory against software with no revenue model from which to pay
such fees. There are also concerns over the leverage this would give large
patent-holding corporations over smaller competitors seeking to implement
W3C standards, and over the fact that software patents are only recognized
in a few countries, but that RAND would give them international reach.

There is also significant (and legitimate) concern over the fact that the
policy review period for RAND was shortened over what is normally given new
policies and that, given the important nature of the change, the policy was
not announced more visible. Many people feel that the W3C has tried to sneak
this one in "under the radar", and had someone not noticed this with just a
few days to spare it would have become working policy for the W3C with no
one having voiced any opposition.

This issue could impact all of our work since we will touch upon standards
that could be potentially impacted. (Microsoft, it is claimed, has key
patents on items in XSLT for instance, that it could decide to exercise RAND
rights on, if the policy is changed. I cannot vouch for this claim, but such
problems could arise.)

We will be adding a link to an article I wrote on the subject to the LISA
homepage (http://www.lisa.org) very soon, but given the short window
remaining for public comment I would encourage anyone who cares about this
issue to visit some of the following links to learn more about the issue
(the Simon Brooke posting in particular is excellent):

* The original RAND proposal:
   http://www.w3.org/TR/2001/WD-patent-policy-20010816/

* The W3C's public response to criticism of the policy:
   http://www.W3C.org/2001/10/patent-response

* The W3C's "backgrounder" page on the issue:
   http://www.w3.org/2001/08/patentnews

* The W3C's FAQ on the RAND proposal:
   http://www.W3C.org/2001/08/16-PP-FAQ

* The W3C's archive of response to the proposal:
   http://lists.w3.org/Archives/Public/www-patentpolicy-comment/

* The following responses are particularly relevant and well thought out:
* (Simon Brooke)
http://lists.w3.org/Archives/Public/www-patentpolicy-comment/2001Oct/0539.ht
ml

* (John Gillmore)
http://lists.w3.org/Archives/Public/www-patentpolicy-comment/2001Sep/0736.ht
ml

* (Bruce Perens)
http://lists.w3.org/Archives/Public/www-patentpolicy-comment/2001Oct/0027.ht
ml

* Dan Gillmore's editorial on the subject:
  http://web.siliconvalley.com/content/sv/2001/09/30/opinion/dgillmor/weblog/
index.htmblog/index.htm

Feel free to pass this message along to anyone who might be concerned with
the issue, either pro or con. (If you know anyone who would be pro RAND,
please have then contact me. We are trying to find someone who will publicly
defend RAND for another article on the LISA website.)

Regards,

Arle Lommel
(LISA and TRG)

Oops. So do I. These two messages came in into different slots in my email
(heaven and rr only knows why), so I didn't see this explanation until
later.
Bye,
Sue Ellen
----- Original Message -----
From: "arle lommel" <fenevad@...>
To: <lisa-its@yahoogroups.com>
Sent: Thursday, July 05, 2001 12:23 PM
Subject: Re: [lisa-its] Re: Translatibility


> Ah, I see what you mean.
>
> Sounds good,
>
> Arle
>
> On 7/5/01 10:04 AM, "Yves Savourel" <yves@...> wrote:
>
> >> I don't see that translate and localize are synonymous *enough* to
> >> use localization exclusively. I can think of cases where they
> >> are potentially different, although such cases might be easily
> >> enough dealt with otherwise to allow use of "localize" as the
> >> general term.
> >
> > I probably didn't word my note correctly, sorry Arle.
> >
> > I didn't meant that translate and localize are similar, au
> > contraire.
> >
> > I would say that 'localize' is at the level above translate.
> > Translation being one of the possible actions to apply to localize,
> > along with other actions (resizing, adapting, changing
> > links/pointers, etc).
> >
> > When it comes to localizing an XML file, we'll have all these tasks
> > to do (or not), not just translate.
> > If the element to 'localize' holds text: we translate, if it holds
> > coordinate we resize, etc. In this context see the word 'localize'
> > as almost a synonym for 'change'.
> > We'll have to know the type of data anyway, so that should let
> > us know what type of action is required on it, the 'localize'
> > properties would simply indicates whether or not that action
> > should be done.
> >
> > I hope it's more clear.
> > -ys
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

As is so often the case, I agree with Arle. I don't think translatability
and localizability are necessarily the same thing.
Sue Ellen
----- Original Message -----
From: "arle lommel" <fenevad@...>
To: <lisa-its@yahoogroups.com>
Sent: Thursday, July 05, 2001 11:31 AM
Subject: Re: [lisa-its] Translatibility


> Hi all,
>
> I have been out of the loop for a little while, and perhaps the following
> issue that Yves' message brought to mind has been addressed:
>
> I don't see that translate and localize are synonymous *enough* to use
> localization exclusively. I can think of cases where they are potentially
> different, although such cases might be easily enough dealt with otherwise
> to allow use of "localize" as the general term.
>
> Some examples are:
>
> 1. You have an English text that is set for translation into French and
uses
> English measurements. What do you do with items such as '2 3/8 in'? In
> general if you were fully localizing the text that would need to become
> '6.0325 cm', but you might decide that you don't want to localize the
> measurements fully, but would like to translate them, in which case you
> might end up with '2 3/8 pouces'. In neither case is the measurement left
> untranslated, but one is localized and one is not and there are very good
> reasons why you might not want to localize the measurements (such as if
you
> were specifying that a machine requires a part '2 3/8 in' in size where
the
> English measurement has some real meaning that is not really expressed by
> '6.0325 cm.'). If, however, you were merely specifying external
measurements
> of something then you very well might want the localized measurements.
>
> (Note that this example leaves out the issue as to whether a pouce and an
> inch are the same thing -- they really aren't -- but they are often
treated
> as being synonyms in English and French by translators and localizers.)
>
> 2. There are cases where it might be appropriate to translate something in
a
> graphic but not localize the graphic or vice versa. In the first case a
> company may decide that it wants to localize its website, but that rather
> than going through the trouble of localizing its graphics they want only
to
> translate terms in them. (I guess this could be handled by specifying at
> some level that the graphic element is not localizable but the text is,
but
> it seems somehow inelegant and bad form to have an element that is not
> localizable contain one that is.) In the second case companies often have
> text that is not to be translated that is contained in localizable
elements.
> (Again nesting specifications could identify this, and here it doesn't
seem
> such a violation of elegance.)
>
> Anyway if this has already been dealt with and I have simply missed it or
if
> everyone thinks this trivial then I apologize for taking up bandwidth.
>
> Regards,
>
> Arle Lommel
>
> On 7/5/01 7:29 AM, "Yves Savourel" <yves@...> wrote:
>
> > 1-- Translate vs. Localize
> > ==========================
> >
> > Depending on its type (a coordinate, a URL, a text content, etc.) we
> > should be able to distinguish from 'translatable' or something else
> > (resizable, link to change, font name to adjust, etc.).
> >
> > So maybe using the more generic term (i.e. 'localize') would be
> > appropriate?
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Ah, I see what you mean.

Sounds good,

Arle

On 7/5/01 10:04 AM, "Yves Savourel" <yves@...> wrote:

>> I don't see that translate and localize are synonymous *enough* to
>> use localization exclusively. I can think of cases where they
>> are potentially different, although such cases might be easily
>> enough dealt with otherwise to allow use of "localize" as the
>> general term.
>
> I probably didn't word my note correctly, sorry Arle.
>
> I didn't meant that translate and localize are similar, au
> contraire.
>
> I would say that 'localize' is at the level above translate.
> Translation being one of the possible actions to apply to localize,
> along with other actions (resizing, adapting, changing
> links/pointers, etc).
>
> When it comes to localizing an XML file, we'll have all these tasks
> to do (or not), not just translate.
> If the element to 'localize' holds text: we translate, if it holds
> coordinate we resize, etc. In this context see the word 'localize'
> as almost a synonym for 'change'.
> We'll have to know the type of data anyway, so that should let
> us know what type of action is required on it, the 'localize'
> properties would simply indicates whether or not that action
> should be done.
>
> I hope it's more clear.
> -ys

> I don't see that translate and localize are synonymous *enough* to
> use localization exclusively. I can think of cases where they
> are potentially different, although such cases might be easily
> enough dealt with otherwise to allow use of "localize" as the
> general term.

I probably didn't word my note correctly, sorry Arle.

I didn't meant that translate and localize are similar, au
contraire.

I would say that 'localize' is at the level above translate.
Translation being one of the possible actions to apply to localize,
along with other actions (resizing, adapting, changing
links/pointers, etc).

When it comes to localizing an XML file, we'll have all these tasks
to do (or not), not just translate.
If the element to 'localize' holds text: we translate, if it holds
coordinate we resize, etc. In this context see the word 'localize'
as almost a synonym for 'change'.
We'll have to know the type of data anyway, so that should let
us know what type of action is required on it, the 'localize'
properties would simply indicates whether or not that action
should be done.

I hope it's more clear.
-ys

Hi all,

I have been out of the loop for a little while, and perhaps the following
issue that Yves' message brought to mind has been addressed:

I don't see that translate and localize are synonymous *enough* to use
localization exclusively. I can think of cases where they are potentially
different, although such cases might be easily enough dealt with otherwise
to allow use of "localize" as the general term.

Some examples are:

1. You have an English text that is set for translation into French and uses
English measurements. What do you do with items such as '2 3/8 in'? In
general if you were fully localizing the text that would need to become
'6.0325 cm', but you might decide that you don't want to localize the
measurements fully, but would like to translate them, in which case you
might end up with '2 3/8 pouces'. In neither case is the measurement left
untranslated, but one is localized and one is not and there are very good
reasons why you might not want to localize the measurements (such as if you
were specifying that a machine requires a part '2 3/8 in' in size where the
English measurement has some real meaning that is not really expressed by
'6.0325 cm.'). If, however, you were merely specifying external measurements
of something then you very well might want the localized measurements.

(Note that this example leaves out the issue as to whether a pouce and an
inch are the same thing -- they really aren't -- but they are often treated
as being synonyms in English and French by translators and localizers.)

2. There are cases where it might be appropriate to translate something in a
graphic but not localize the graphic or vice versa. In the first case a
company may decide that it wants to localize its website, but that rather
than going through the trouble of localizing its graphics they want only to
translate terms in them. (I guess this could be handled by specifying at
some level that the graphic element is not localizable but the text is, but
it seems somehow inelegant and bad form to have an element that is not
localizable contain one that is.) In the second case companies often have
text that is not to be translated that is contained in localizable elements.
(Again nesting specifications could identify this, and here it doesn't seem
such a violation of elegance.)

Anyway if this has already been dealt with and I have simply missed it or if
everyone thinks this trivial then I apologize for taking up bandwidth.

Regards,

Arle Lommel

On 7/5/01 7:29 AM, "Yves Savourel" <yves@...> wrote:

> 1-- Translate vs. Localize
> ==========================
>
> Depending on its type (a coordinate, a URL, a text content, etc.) we
> should be able to distinguish from 'translatable' or something else
> (resizable, link to change, font name to adjust, etc.).
>
> So maybe using the more generic term (i.e. 'localize') would be
> appropriate?