Reformat Element In XLIFF

 

From the XLIFF 1.0 Specification

reformat

Reformat - Indicates whether the target can be formatted (size, font, etc.) different than the source.

Value description:

Boolean: yes or no.

Default value:

yes.

Used in:

<trans-unit>, <bin-unit>.

 

Issues

1)      The list of attributes controlled by reformat attribute is not closed

2)      The reformat element does not permit individual elements in this list to be selected

3)      The reformat attribute element is not permitted within prop group

4)      New Issue: Font and Coord attributes are not well defined

 

Details of Issues

1)      The list of attributes controlled by reformat attribute is not closed

If an XLIFF compliant tool is capable of making changes to format related elements, the 1.0 spec does not specify which elements/attributes may be modified.

If the list is left open, there is no mechanism for individual tool developers to know, or for XLIFF providers/extenders to specify, the XLIFF attributes that are format related.

 

 

2)      The reformat element does not permit individual elements in this open list to be selected

The reformat attribute does not allow an XLIFF document to specify that some members of the list may be modified, and others may not. In some cases we may not be allowed to resize a control, but we may need to change the font name, keeping the font size.

 

3)      The reformat attribute element is not permitted within prop group

We have agreed that prop and prop-group will be deprecated in XLIFF 1.1. This issue can be closed

 

4)      New Issue: Font and Coord attributes are not well defined

[YS: I agree on 'not well defined' and would expend that comment to menu, menu-option, style, exstyle, css-style, etc., basically all the attributes that carry information that are only "borderline generic".]

Discussing this document with other developers has raised some concern over the format of attributes such as font and coord. These attributes contain multiple values with delimiting characters.

Since these structures appear in free form text within the attribute, it is impossible to validate that they are structured correctly.

[YS: XML Schema allows (at least to some extend) to validate such content using pattern and regular-expression (http://www.w3.org/TR/xmlschema-2/#regexs).]

We would suggest expanding the definition of these structures into full elements.

 

 

 

Proposals

 

1)      Close the list of elements, attributes that are controlled by reformat.

John Reid noted that the list of attributes controlled by Reformat attribute
should not be closed.

 

Gerard pointed out that the paradigm for describing resource attributes may change in the future, and closing such a list may result in future incompatibility.  Tony agreed, and suggested that the word "closed" be struck off the proposal, and suggested that a list of presently known attribute values be defined, but that the list be user extensible.

 

This is accepted

 

 

      2)      Implement a Reformat element

The reformat element would allow an XLIFF document to specify which members of the list are reformatable.

 

The reformat element is interchangeable with the reformat attribute.

Listing all reformattable attributes within reformat elements is synonymous with a reformat attribute.

 

As the attribute refers to an open list, the elements can better define the members of this list that are to be controlled.

 

Each element contains two attributes

 

The first attribute is either element or attribute

The second attribute is edit

<reformat element =”coord” edit=”false”/>

<reformat attribute=”ORA_XLIFF:CLSNM” edit=”false”/>

 

The value for edit may be true or false, with a default value of false

 

 

Individual members of an element mat be controlled using attribute

<reformat attribute =”coord:cx” edit=”true”/>

[YS: Maybe using @ for attribute separator would be better, as ':' maybe used for namespace?]

[YS: Maybe using XPath expression would be better?]

 

[YS: what are the defaults (and how do we specify them in XML Schema)?
Using element versus attribute changes how values are (or can be) propagated: no cascading mechanism. I'm concern about how much more information we would have to put on the file.]

 

[Note: we need to be much more clear on how attributes and possibly elements are "inherited" or if they are]

 

 

[YS: Suggestion maybe (not sure if it's a good idea: Maybe the first parameter could have several items listed (<reformat element="coord style exstyle" edit="yes"/> so only one <reformat> element could be used for several items)?]

 

Scope of reformat element

If the elements are used as an alternative to the reformat attribute, then there are good reasons for allowing identical scope of usage.

Therefore the elements should also be used in trans and bin units with the same scope rules.

 

 

 

3)      Allow Reformat attribute within prop group.

This issue is closed

 

4)      Replace font and coord attributes with font and coord elements

The font and coord attributes use multipart values separated by delimiter characters. These attributes are free form text and cannot be validated.

These attributes, and any other attributes that use this delimiter mechanism, will be replaced with elements capable of showing and validating the internal structures of these values.

 

The font and coord attributes are permitted but deprecated in XLIFF 1.1

 

The coord element takes four values

x, y, cx and cy.

[YS: Do we need an element for coord. the same result would be done with having c, y, cx, and cy as attribute instead of the coord attribue]

 

Any values not specified are considered to be undefined

The font element takes

            fontName

            fontStyle

            fontWeight

            fontSize

 

The allowed values for fontWeight are

normal bold | bolder | lighter |

100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900

The allowed values for fontStyle are

 

normal | italic | oblique

 

fontSize and fontName are free format

 

[YS: Don't we have a naming convention policy about lowercase names?]

 

[YS: I would argue that this is a Windows-specific set of value. For example XML data would often use CSS-type font descriptions where there are many more information (http://www.w3.org/TR/REC-CSS2/fonts.html) this culd be handle by css-style attribute, but then why having 2 ways to specify font? This leads back to the question that maybe some attribute are too specific to be part of XLIFF core (?) and should have their own namespace.]

 

 

 

Code Sample

 

 

 

<trans-unit id="1" translate="yes" ORA_XLIFF:CLSNM=”1”>

 

<font fontName=”Arial”  fontSize=”8” fontWeight=”bold”/>

 

<coord cx=“183” cy=”272" />

 

<reformat element=”font” edit=”true”/>

<reformat element =”coord” edit=”false”/>

<reformat attribute=”ORA_XLIFF:CLSNM” edit=”false”/>

 

<source>OK</source>

</trans-unit>

 

[YS: maybe for the edit attribute: "yes" "no" rather than "true" and "false" to be consistent with other Boolean attributes we already have?]

 

The above example shows

 

1)      The proposed font element

This corresponds to the XLIFF 1.0       Font=”Arial:8:bold”

 

2)      The proposed coord element

This corresponds to the XLIFF 1.0       Coord=”#;#;183;272”

Note that only cx and cy are specified. X and y are undefined.

 

 

3)      The proposed reformat elements

 

4)      An attribute form an external namespace being controlled by reformat