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] | [List Home]

Subject: Fw: [xliff-comment] XLIFF 1.2 errata, questions and comments


Date: Mon, 14 Jul 2008 15:13:27 +0200
From: "Uhrig, Stefan" <stefan.uhrig@sap.com>
To: <xliff-comment@lists.oasis-open.org>
Subject: [xliff-comment] XLIFF 1.2 errata, questions and comments


I'm developer at SAP and currently trying to implement XLIFF 1.2. I've
already noticed the XLIFF 1.2 errata on
http://wiki.oasis-open.org/xliff/XLIFF1.2/Errata, but I think I've found
some additional errata in the specification and the provided schemas.
Furthermore I'd like to ask some questions.

I'll start with what I consider errata.

Section 2.5.1:

The <body>-element is missing in the example XLIFF code.

The example schema in this section won't work this way in conjunction
with the previous example. Attribute targetNamespace should read
targetNamespace="http://www.ChaucerState.ac.pg/Frm/XLFSup-v1"; instead of
targetNamespace="XLFSup-v1". Furthermore line
xmlns:sup="http://www.ChaucerState.ac.pg/Frm/XLFSup-v1"; should read
xmlns="http://www.ChaucerState.ac.pg/Frm/XLFSup-v1"; as prefix "sup" is
not used in the schema.

Section 2.5.2:

The <body>-element is missing in the example XLIFF code, too.

Section 3.2.1:

According to specification content of the <glossary> element consists
of the "glossary description and either exactly one <internal-file> or
one <external-file> element". However, the schema allows either exactly
one <internal-file> or one <external-file> element only, but no glossary

Same as above for <reference>: According to specification content of the
<reference> element consists of "A description of the reference
material and either exactly one <internal-file> or one <external-file>
element". However, the schema allows either exactly one <internal-file>
or one <external-file> element only, but no reference material

Attribute "phase-name" in element <phase> is typed as "string" in
schema. However, in elements <target>, <alt-trans>, <bin-unit> and
<bin-target> it is typed as "NMTOKEN". Therefore the schema allows to
create phases by names you cannot reference in the above elements.

Section 3.2.2:

According to specification content of a <count-group> element consists
of "One or more <count> elements". The schema allows zero <count>
elements, too.

According to specification in element <count> the attribute
"count-type" is required. However, it is optional in the schema.

Could you please provide some recommendations for the cases in that the
schema is different from the specification? Are you planning to publish
a revised XLIFF 1.2 specification?

Additionally I came across some ambiguities, especially typing of
attributes in the schema is too lax in my opinion.

There are a lot of attributes with value description "Number" (e.g.
minheight, maxheight, minwidth, maxwidth, minbytes, maxbytes). I would
expect a numerical type at least in the schema, and for some attributes
even an integer type (like for minbytes and maxbytes). However, the
schema types them as string. This makes life of implementers hard,
after the check against the schema a parser still has to check if he
"understands" the attribute value. Is there a reason for this lax

On attribute "coord" the specification states that cx and cy represents
the width and height as in Windows resources. The schema allows signed
integers for cx and cy. However, the Windows resource specification
(http://msdn.microsoft.com/en-us/library/ms907882.aspx) states that
width and height are unsigned integers in the range from 1 to 65,535.
What are valid values here?

I don't understand why content of attribute "mime-type" should only
"roughly" correspond to the content-type of RFC 1341. It would be much
easier for implementers if it would strictly correspond to RFC 1341.
Indeed the schema allows values that are not valid according to RFC
1341 (e.g. type "model", subtype is mandatory according to RFC 1341,
schema allows subtype-characters that are invalid according to RFC
1341). On the other hand there are valid mime-types (according to RFC
1341) that are not allowed by XLIFF-schema (for example "X-test/test").
Furthermore: while there is some pattern-typing for attribute
"mime-type", the related attribute "form" is not typed this way. Is
there a reason why "mime-type" and "form" are not required to
correspond exactly to RFC 1341?

Regarding attributes "minbytes" and "maxbytes" the specification states
that the "verification of whether the relevant text respects this
requirement must be done using the encoding and line-break type of the
final target environment". However, XLIFF 1.2 specification does not
offer a dedicated place where to store information on the target
environment. Of course, a tool can specify them using one of the
extension points but that will affect interchangeability in a negative
way as implementers will do that in different incompatible ways. What
is the correct way to evaluate these attributes?

Best Regards,
Stefan Uhrig

Rodolfo M. Raya <rmraya@maxprograms.com>


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