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: Re: [xliff] XLIFF 1.0 issues

Hi All,

My comments follow Mark's, between <jr>...</jr> tags. 

>>> Mark Levins <mark_levins@ie.ibm.com> 4/5/02 5:59:53 AM >>>

1. <note> as a child of <count>
Currently the <count> element is very ambiguous, a note as a child
could be used to indicate what was being counted, what was considered a

word etc.

<jr>The <count-group> and <count> elements can be very problematic. A
<note> element within the <count> element may help in the customized
support required by these elements but that is a human readable approach
and probably would need to be defined even more to be truly useful. A
stronger definition of the count element may do more for us. 
<count> has the 'unit' attribute which has recommended values of word,
page, trans-unit, bin-unit, and item. The latter three are defined
according to elements within the spec but the former two must be defined
by the tool creating the count. I suggest that we include the tool as an
attribute to the count-group. This would be the same attribute used in
<file>, <phase>, and <alt-trans>. Further refinement of the 'unit'
attribute may alo be necessary.</jr>

2. The <count-group>, <prop-group> and <context-group> elements can be

used within a <group> without any other relevant child elements
The 1.0 specification allows that a <group> element can contain (for 
example) a <count-group> without containing anything to count. I think
<group> element should be changed to contain at least one of <group>, 
<trans-unit> or <bin-unit>.

<jr>Shouldn't this requirement be placed on the <body> also?</jr>

3. Binary elements & <internal-file>
This is kind of a big one. At the moment the specification does not
the form of the content of the <internal-file> element (although there
an optional 'form' attribute). The problem is see with this is that the

specification allows users place binary data directly as content - this

binary content may contain the reserved XML characters < > etc which
cause parsers to choke.
The CDATA section approach is also not good enough to provide a
My suggestion is that the content of the <internal-file> be restricted
Base64 or at least stated so.
Also, the description in the spec for the <internal-file> element reads

"The <internal-file> element will contain the data for the skeleton
which is technically wrong, it may also contain data for an
or <bin-target> element.

<jr>How does CDATA fail this purpose? I wouldn't want to restrict this
to just Base64; thus, requiring a conversion for both the producer and
any subsequent processor that may be able to handle the original format
without a problem. Additionally, wouldn't we need an attribute such as
'original-format' if we forced your conversion?</jr>

4. mime-type attribute of <bin-source>
How come this attribute is omitted from the <bin-source> element? Note

that it is an attribute of <bin-target>

<jr>We generally put attributes for <source> and <bin-source> in the
parent, <trans-unt> and <bin-unit>, respectively. The 'mime-type'
attribute of the target allows a different mime-type for the target in
cases where it differs from that specified from the <bin-unit>'s.
Otherwise, the mime-type of the target is unnecessary.</jr>


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

Powered by eList eXpress LLC