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: [xliff] reformat discussion

Following the recent emails from Yves, John and Matt (via Tony) and Tony I figured I'd add a few of my own thoughts...

Both Yves and John have tabled very strong arguments for the deferral of the changes to our next major release. I fully agree with the need to get XLIFF out there and published formally as soon as possible. However, in the light of the amount of time it has taken to 'rubber-stamp' XLIFF 1.0 under the umbrella of OASIS as XLIFF 1.1, I am concerned as to when the specification might formally address the problem of localization of non-linguistic data. Somehow we managed to overlook this requirement in the original specification and this omission is also out of line with our mission statement. I would very much like to include a new method for handling meta-data in XLIFF 1.1 as I see it as providing for richer support of the whole localization process than just 're-formatting'.

John mentioned that the problem we are trying to address has not been properly formally expressed. This is how I would state it: "XLIFF does not currently provide a mechanism for the localization of localizable data in the absence of text. It is also inelegant and unintuitive in its approach to modifiable data associated with text and lacks the ability to indicate the presence of modifiable or, more importantly, non-modifiable data".

Extending then from Matt's recent reformat summary I think we can use a slight variation of option 4 as stated in his mail (i.e. 'Combined'). I would like to use more intuitive naming though, for example, something along the lines of <extended-source> and <extended-target> or <ex-source> and <ex-target> etc instead of <source-info> and <target-info>.
Matt had stated that this option would require the most complex schema definition but I don't think that there's any real obstacle here.
I have included a modified excerpt from the schema for the <trans-unit> element to demonstrate that the changes are not exorbitant.

        <xsd:complexType name="ElemType_trans-unit">
                                        <xsd:element name="source" type="xlf:ElemType_source"/>
                                        <xsd:element name="target" type="xlf:ElemType_target" minOccurs="0"/>
                                        <xsd:element name="ex-source" type="xlf:ElemType_ex_source"/>
                                        <xsd:element name="ex-target" type="xlf:ElemType_ex_target" minOccurs="0"/>
                        ...rest of sequence removed for brevity
                <xsd:attribute name="id" type="xsd:NMTOKEN" use="required"/>
                ... removed attributes for brevity ...
                <xsd:anyAttribute namespace="##other" processContents="lax"/>

Finally, as I've just received Shigemichi's mail, I would like to second his thoughts and change my previously stated preferred option from #2 to #4. I also think Shigemichi summarizes the backward/forward compatibility issue very well and the combined option fits here (IMHO).


Mark Levins
IBM Software Group,
Dublin Software Laboratory,
Airways Industrial Estate,
Dublin 17,
Phone: +353 1 704 6676
IBM Tie Line 166676

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

Powered by eList eXpress LLC