Magnus and all:
Thanks for the recommendations.
The revision to 1.2 is being introduced
specifically to add segmentation support into the 1.1 spec. While we’ve
got the hood (or bonnet) open, it also makes sense to add a few bug fixes and
clarifications. If your suggestions don’t generate much
controversy, then I think we can make some of the recommended changes in the
spec. Given that our TC focus is on submitting XLIFF to the official standards
process, if we can’t agree on these changes by the next TC meeting, then I
suggest we set them aside to discuss at the next XLIFF revision.
My personal observations and opinions on
your recommendations are as follows:
1: I prefer to keep coord, style, exstyle,
extype in the spec as they’re resources that are quite generic across technologies.
I think it’s much easier and more efficient than using “context”
to track this information.
2. No opinion
3. Seems like a good idea. I will think
a bit more on it to see if it has any negative implications that aren’t
readily obvious.
4. No opinion. You make some good
points though…
5. I disagree – I think the “restype”
attribute is a very useful (critical, really) attribute. Although using “context”
is feasible to track the resource type information, it’s just not nearly
as simple and effective as the existing “restype”. If this
recommendation was adopted, presumably we would have to modify “context”
to be required as well. I think this one should stay as it is... but
let’s hear the opinion of other TC members.
Regards,
Tony
-----Original Message-----
From: Magnus Martikainen
[mailto:]
Sent: 20 September 2005 18:51
To: ;
Tony Jewtushenko
Subject: [xliff] Suggested
additional changes for XLIFF 1.2
Hi Tony etc.,
Following up on the conference call
today, here are my suggestions for additional changes of the XLIFF 1.2
specification:
1) The following attributes seem to
be used only for file format specific purposes. I propose deprecating them, as
we should rather use the extension mechanism for such things:
·
extradata
·
menu
·
menu-option
·
menu-name
·
coord
·
css-style
·
style
·
exstyle
·
extype
In addition to this I have the
following proposals:
2) The name attribute for
<context-group> is currently marked as REQUIRED. (The specification
indicates that this attribute should only be used for processing instructions.)
I propose to relax this rule and allow the name attribute for a
<context-group> to be optional.
3) I propose to add an extension
point at the <xliff> level. This would be useful for providing
information that is common to all the files in the XLIFF document. Some
examples of what this could be used for:
·
Job / project information
·
Contact details
·
Tool settings
·
Copyright information
·
General instructions,
·
Embedded style guides
·
Analysis reports
·
Pricing information
4) I propose to deprecate the
<sub> element in favour of using the xid
attribute and putting the embedded translatable content inside a separate
<trans-unit>. Reasons:
·
The two mechanisms are used for the same purpose.
·
The xid mechanism is superior to the <sub>
mechanism.
·
The <sub> element content disrupts the text
flow. It requires tricky special processing by XLIFF compliant tools, and can
also be distractive during translation. Removing it will make it easier to
create good XLIFF compliant tools.
·
The content of the <sub> is a separate unit for
translation, and as such is much better represented in its own
<trans-unit>.
·
More context information can be provided for a
separate <trans-unit>. E.g. length restrictions for the embedded content
can be expressed.
·
Keeping the embedded translatable content in a
separate <trans-unit> will yield better recycling. Both the surrounding
text and the embedded content can be treated as separate units. One can be
re-used if the other changes, and if the same embedded content appears in
different text it can be re-used independently.
5) I propose to deprecate the
restype attribute in favour of using the
<context> element to provide context information. Reasons:
·
The two mechanisms serve a similar purpose and can be
used for the same thing. Providing two ways to do the same thing makes
interoperability more difficult.
·
The <context> mechanism is more powerful than
the restype attribute
·
The restype values in the current specification are
highly file format specific.
·
If multiple contexts apply it is not clear if one can
specify more than one value for a restype attribute.
Best regards,
Magnus Martikainen
