[xliff] reformat discussion

[Mark Levins <mark_levins@ie.ibm.com>]

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

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).

Regards,

Mark Levins

IBM Software Group, Dublin Software Laboratory, Airways Industrial Estate, Cloghran, Dublin 17, Ireland.

Phone: +353 1 704 6676 IBM Tie Line 166676