Re: [xliff] xLiff and Interoperability

[Stephen Holmes <sholmes@novell.com>]

 

Wouldn't every parser parse everything in a given XLIFF file anyway? 

 

The elements a given tool chooses to display to a user is pretty much context dependent.  So following on from Enda's comment can we say that "if a given attribute is in the XLIFF then we should simply require that a tools implementation parse it , but that we don't require the tool to have specific methods to operate upon it". 

 

Tools that don't process a given tag, entity or attribute should be obliged to write out exactly what they read in if they don't operate on the content specifically!

Steve.

 

 

 

 

S  t  e  p  h  e  n     H  o  l  m  e  s
Localisation Development Manager
International Product Development

 

Voice:  +353 (1) 241 5732
Fax:     +353 (1) 241 5749

 

Novell, Inc., a leading provider of Net business solutions
http://www.novell.com
>>> Enda McDonnell <EndaMcD@alchemysoftware.ie> 03/06/02 06:09 >>>
Hi All,


xLiff is young at this stage and perhaps the interoperability Eric asked
about has not yet been proven; many tools have not had time to endorse it
fully. However, the use of TMX between tools is a good example of the
interoperability that can be achieved with xLiff as it is.

TMX, which has many of the same interoperability limitations we are
discussing wrt xLiff 1.0, has been used to great effect between tools.
There are many examples where localisation data has been transferred between
tools. The stronger commercially available localisation tools now support
TMX. While that support is to differing levels, it proves that the tools
can work with the flexibility that has been built into TMX and the current
xLiff spec.



Regarding interoperability, there are certain key pieces of data such as
source and target text, parts of speech, translator notes, etc that are
critical to all stages of the localisation process and need to be fully
understandable by all consumers of xliff. There is other data that is
completely specific to the author of the xliff file and is irrelevant to
other users. Examples might be database unique keys from where the text
came, or specific workflow paths within an organisation. These do not need
to be understood by everyone, yet absolutely need to be catered for in this
format.

I don't believe that a flexible attribute such as 'ts', which xliff uses for
this type of information, prevents interoperability. This may not be the
best way of providing flexibility, but we need to understand that if this
format is supposed to span the entire localisation process for any
organisation, we need to provide a mechanism that allows users include
proprietory information that is simply maintained by consuming applications
that do not understand it.

I am very much in favour of interoperability and tightly specifying as much
as possible in xLiff 1.1, but I feel some flexibiltiy would promote the
format greater adoption in the industry.


Regards,
Enda





-----Original Message-----
From: Friedman, Eric [ mailto:eric@ConveySoftware.com]
Sent: 06 March 2002 15:16
To: 'Peter Reynolds '; ' xliff@lists.oasis-open.org '
Subject: RE: [xliff] Minutes of the XLIFF TC March 5th. 2002


Hi folks,

On Wed, 6 Mar 2002, Peter Reynolds wrote:

> I share your frustration with people describing the current spec as
> unworkable. We are also working with XLIFF and doing fine on the current
> spec. Considerable work went into achieving the 1.0 spec and I don't think
> it is helpful for that to be dismissed.

No one has "dismissed" the work that has been done up to date. I can
only speak for myself on this subject, but if I thought the current
document was worthless, I wouldn't have bothered to get involved.

I've heard from several people that they have working implementations
of the current specification. I think that's a terrific indicator that
things are going well. However, I have >not< heard from anyone who
has successfully done work using their tools in combination with
those produced by someone else in the group without access to information
beyond the contents of the shared spec.

The abstract of the spec is very clear on this point: "The purpose of
this format is to store localisable data and carry it from one step of
the localisation process to the other, while allowing interoperability
between tools."

Has someone achieved that "interoperability between tools"? That's
what I want to see happen, because it has much more value than
yet another format that only works with tools from this-or-that
vendor.

Eric

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: < http://lists.oasis-open.org/ob/adm.pl >

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: < http://lists.oasis-open.org/ob/adm.pl >