OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

Subject: RE: [xliff] Embedded XLIFF

my five coments:

Identification of Localizable Parts:

The loc tool to process the directives (or for any loc process) should work without any knowledge about primary format. This is a very important constraint.  

Also, no primary format information should be duplicated in the loc directive namespace.

Here is the example.

BAD: it implies the string is the text content of the element.
<data ld:localize="yes"> 
	this is my string

GOOD: the xpath provide a standard way to access source string. We can make "./text" be the default when ld:ref is absent.

<data ld:ref="./text/" ld:localize="yes" >
	this is my string

Usage of ld: tags, such as 
<p>See the 
	<ld:span localize="no">XML Inclusions (XInclude) Version 1.0
	</ld:span> document for more information.

can really screw up the validation against the primary format schema if any. It requires the primary schema to import the ld namespace and insert ld tags all over the primary schema. I provided example to illustrate my point before. I hope XML standard body can relax the validation so that tags in different namespaces can always be valid. 

Unique Identifier
In a lot of cases, the unique id is already available in the primary format. We should allow ref into that namespace. Example: here is the primary data:

<data resID="123456" >
	this is my string

the method said in your doc, 

<data resID="123456" ld:id = "abcdef">
	this is my string

I think we should allow this:

<data resID="123456" ld:idRef="@resID">
	this is my string

Identification of Changes
I don't think it pays off for the complexity of managing changes. Business can always send multiple version of docs if changes are important.

Scope of directives (new)
In order to simplify the creation of xml docs with loc directive, we need to have idea of scopes. Some directives may apply to the whole document while some other my apply only to the current element and its child elements. Come  with it is the override rules. Typically, the directive that closer to the target in the primary content should override the directives that farther from it.

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Tuesday, June 11, 2002 3:22 PM
To: XLIFF list
Subject: [xliff] Embedded XLIFF

To follow up on the discussion about embedded XLIFF, here is a basic
proposal for requirements (not a proposal for the actual tags).

It's directly inspired from the one created by ITS, but focused on the
localization directives aspects (ITS's requirement was broader). I've also
tried to have various examples (with different possible notations) to
illustrate how this could be used. The mapping to XLIFF constructs is
usually easy.

Note that I've put all requirements I could found, even if some are resolved
already (like language identification with xml:lang).


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

Powered by eList eXpress LLC