Title: Reformat Summary Of Options
I have finally had a chance to read Doug's mail in
depth
I fully endorse his new proposal
While it may not be as neat and pretty as option 2,
it does five us all the required control while remaining compatible with
1.0
I would be happy to use this new proposal in 1.1,
and we can have another look at option 2 in XLIFF 2.0
Mat
----- Original Message -----
From:
Doug Domeny
To:
Sent: Thursday, January 23, 2003 6:05
PM
Subject: RE: [xliff] From Mat Lovatt:
reformat Summary Of Options.doc
Thank you for the summary, Tony. I agree with the
options, but I have a few comments about compatibility and the need to retool.
And I actually have another option too.
I
refer to the guideline for minor releases (http://lists.oasis-open.org/archives/xliff/200208/msg00005.html).
Shall be comprised
of small changes that would not require re-qualification of supporting tools
or technologies
There are several aspects to compatibility to
consider:
1.
XLIFF 1.0 document validates against XLIFF 1.1 schema. Given the flexibility
of schemas, it would almost always be possible to create a schema that allowed
both 1.0 and 1.1 structures.
2.
XLIFF 1.1 tool can process either XLIFF 1.0 or 1.1 documents without
requiring extensive effort to handle XLIFF 1.0 documents.
3.
XLIFF 1.0 tool can process either XLIFF 1.0 or 1.1 documents without
modification (assuming a reasonably careful
implementation).
Aspects #1 and #2 deal with backward compatibility (from the tool's
perspective). That is, new tools and new schemas handle old data. The issue is
not one of possibility, but of practicality. Is it easy to create the
tools?
Aspect #3 is forward compatibility (from the tool's perspective). That
is, can the old tool handle the new data? This is similar to asking whether MS
Word 97 can read a MS Word 2000 document (allowing for some loss). Another
example is whether an old browser, say IE 3, can render a new HTML document,
say XHTML 1.0. Again, allowing for some loss for unknown tags. The
primary rule for forward compatibility in a browser is, "render the contents
of an unknown tag". This aspect of forward compatibility is crucial to meeting
the guideline for not re-qualifying supporting tools.
XLIFF tools, however, are not as simple as browsers. An XLIFF tool must
be able to modify the contents, not just render them. Because the contents
must be modified, the XLIFF tool requires more knowledge of the tags. This is
why adding extension points (non XLIFF tags) to content within <source>
and <target> has been deferred.
Here
are some comments regarding each option listed below as they pertain to
"re-qualification of supporting tools or technologies".
Option 1 (siblings)
I
believe this is forward compatible, assuming the tool doesn't assume that
<target> immediately follows <source>.
The
other concern is how <target-info> appears in <alt-trans>
where multiple <target> elements are allowed.
I
took another look at the XLIFF 1.0 DTD. Here are the <trans-unit> and
<alt-trans> definitions:
<!ELEMENT trans-unit
(source,target?,(count-group|note|context-group|prop-group|alt-trans)*)
>
<!ELEMENT alt-trans
(source?,target+,(note|context-group|prop-group)*) >
The
new DTD would be:
<!ELEMENT trans-unit (source, source-info?,
target?, target-info?,(count-group|note|context-group|prop-group|alt-trans)*)
>
<!ELEMENT alt-trans
(source?, source-info?, (target,
target-info?)+, (note|context-group|prop-group)*)
>
I think we all have some reservations
about this approach because it is awkward to have two source elements and
worse yet, difficult to match a given <target-info> element with its
corresponding <target> element.
Option 2 (restructure)
We
all agree this is a clean structure but not compatible.
Option 3 (embedded)
Allow me to given a different example using a <font> tag and a
placeholder tag.
<trans-unit id="Option 1" translate="yes >
<source><font face="Arial"
size="2">
</font><ph/>Source
Text</source>
<target><font face="Arial"
size="3">
</font><ph/>Translated
Text </target>
</trans-unit>
The
inclusion of extension points for <source> and <target> are
deferred because they introduce unknown tags into text that is processed by a
TM tool. This option introduces unknown tags to the text content. This option
isn't fully compatible because the TM tool will need to ignore <font>
and other unknown tags. Granted the unknown tags should come before the rest
of the text to be translated, but I still do not believe it is forward
compatible.
Besides, correctly parsing this structure is almost impossible. How
does the tool know which tag is the last format tag and which is the first
inline "placeholder" tag? Adding more "placeholder" tags to the specification
would be impossible because the tool would have to assume any unknown tag is a
format tag. This appears to not be a viable option.
Option 4 (combined)
This
really isn't technically different than Option 2 other than to say that the
XLIFF 1.1 schema and XLIFF 1.1 tools must support the old XLIFF 1.0 structure
as well as the new structure. I do believe the effort is minimal to have the
<source-info> and <target-info> tags be optional. However, if they
are present, they will likely to break existing XLIFF 1.0 tools that look
for the <source> as an immediate child of <trans-unit>. For
instance, my existing XSL transforms would need to be updated to support
XLIFF 1.1 documents. Therefore, this option isn't fully compatible with 1.0
even though it is backward compatible.
With
all this said, I went back to determine the original purpose for proposing
elements for reformatting. The issue is concerning being able to specify which
format values may be modified during translation. In XLIFF 1.0, as you know,
there are several attributes to specify formatting for the text.
Namely, coord, font, css-style, style, and exstyle. The 'reformat'
attribute of <trans-unit> is either "yes" or "no" indicating whether any
or none of the format attribute values can be changed. The changed value is
stored in the <target> tag.
The
problem is that 'reformat' does not give sufficient control to be able to say
that some formats may be changed, but others cannot. For example, it is
allowed to change the coord-cx, but not coord-x or coord-y. The original
proposal was to move each format attribute to be elements and each element
would have its own 'reformat' attribute. This approach is fine except for the
compatibility problems that have been discussed at length.
Here's the new option.
Extend the possible values for the 'reformat' attribute to provide
sufficient control. XLIFF 1.0 presently uses ";"-delimited lists within
attribute values to store multiple values. The 'coord' attribute is an
example. It's value is actually four: "x;y;cx;cy", where "#" can be used
for 'don't care'.
So
let's extend 'reformat' the same way. Of course, we keep "yes" and "no" for
compatibility.
"yes" = all format attributes may be changed
"no"
= no format attributes may be changed
...or a semicolon-delimited list of the following in any order. If an
attribute is listed, it means it may be reformatted.
coord = all 4 coords
coord-x
coord-y
coord-cx
coord-cy
font
= all 3 font values
font-name
font-size
font-weight
css-style
style
exstyle
Example,
<trans-unit coord="#;#;183;272" font="Arial;2;normal"
reformat="coord-cx;font-name" ...>
<source>...</source>
<target coord="#;#;181;272"
font="System;2;normal">...</target>
<alt-trans coord="#;#;183;272"
font="Arial;2;normal">
<target coord="#;#;180;272"
font="Arial Bold;2;normal">...</target>
<target coord="#;#;185;272"
font="Arial, Helvetica;2;normal">...</target>
</alt-tran>
</trans-unit>
Parsing the reformat list is fairly easy, even with XSLT, which has a
limited set of string functions.
This
option is 100% compatible, both forward and backward. It does not affect the
structure at all. The only problem I can foresee an XLIFF 1.0 tool having is
if an invalid value for reformat is assumed to be "yes" instead of "no" and
allows some values to be changed that should. That is, an XLIFF 1.0 tool could
interpret a value of "coord-cx;font-name" as "no" and not allow any of the
format value to change. Of course, if it assumed "no" instead of "yes" it
would not allow any changes. Since the default value for 'reformat' is "yes",
I don't see either of the possibilities as being too
harmful.
Regards,
Doug Domeny
Ektron, Inc.
+1 603
594-0249
http://www.ektron.com
-----Original Message-----
From: Tony Jewtushenko
[mailto:]
Sent: Thursday, January 23,
2003 9:22 AM
To:
Subject:
[xliff] From Mat Lovatt: reformat Summary Of
Options.doc
Reformat Summary of
Options
Objective
Additional elements such
as font, coord need to be associated with source and
target
There are 4 proposals that I shall
call
1)
Siblings
2)
Restructure
3)
Embedded
4)
Combined
Option 1 - Siblings
The <source-info>
and <target-info> elements
Are made siblings of
<source> and <target>
<trans-unit
id="Option 1" translate="yes >
<source>Source
Text</source>
<source-info>
<coord>
<x reformat =
“no”>x </x>
<y reformat =
“no”>y</y>
<cx reformat =
“yes”>cx </x>
<cy reformat =
“yes”>cy</y>
</coord>
</source-info>
<target> Translated Text
</target>
<target-info>
<coord>
<cx>cx
</x>
<cy”>cy</y>
</coord>
</
target-info >
</trans-unit>
Issues
1)
Is Fully 1.0
compliant
2)
Two extra elements are
required, each containing the same elements
Option 2 –
Restructure
Completely new
structures are used
The text element
replaces the existing source and target
elements
<trans-unit
id="Option 2" translate="yes">
<source-info>
<text>Unable to
store persistent object</text>
<coord>
<x reformat =
“no”>x </x>
<y reformat =
“no”>y</y>
<cx reformat =
“yes”>cx </x>
<cy reformat =
“yes”>cy</y>
</coord>
</source-info>
<target-info>
<text>Unable to
store persistent object translated</text>
<coord>
<cx>cx
</x>
<cy”>cy</y>
</coord>
</
target-info>
</trans-unit>
Issues
1)
Is not compatible with
1.0
2)
Has clean
structure
Option 3 –
Embedded
The existing source and
target elements can contain additional elements within their
content
The actual “Text” is
found between the closing brace of the last additional element and the
<\target> mark
The following example
also shows how white space issues will need to be
handled
The extra elements need
to be specified and implemented in a specified order, e.g. <coord>,
<font>, <….>text
<trans-unit
id="Option 1" translate="yes >
<source><coord>
<x reformat =
“no”>x </x>
<y reformat =
“no”>y</y>
<cx reformat =
“yes”>cx </x>
<cy reformat =
“yes”>cy</y>
</coord>Source
Text</source>
<target><coord>
<cx>cx
</x>
<cy”>cy</y>
</coord>
Translated Text </target>
</trans-unit>
Issues
1)
is fully compatible with
1.0
2)
Is
messy
Option 4 –
Combined
Option 2 is combined
with existing 1.0 structures
The schema says that a
trans-unit contains either
<source> and
<target>
or
<source-info> and
<target-info>
Issues
1)
Is fully compatible with
1.0
2)
Is the cleanest
implementation
3)
Will require the most
complex schema definition
