[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XLIFF 1.2.1 questions
XLIFF TC, Q1: Sample_AlmostEverything_1.2.1_strict.xlf contains a custom
element before the <file> <xliff xmlns="urn:oasis:names:tc:xliff:document:1.2.1" The specification defines the <xliff> element contents
as: One or more Therefore, the <tek:header> element must be AFTER <file>,
not before it. Do we want to keep this definition (and change the sample) or change
the specification/schema to allow custom elements to be mixed with <file>
elements within the <xliff> element? See Errata 1. http://wiki.oasis-open.org/xliff/XLIFF1.2/Errata#head-2dd58fbcd2e0fefdddacfd1e40d85eee3a977759
(note: the transitional sample is OK because it does not have the
<tek:header> element.) Q2: 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? http://lists.oasis-open.org/archives/xliff-comment/200807/msg00000.html
Q3: 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? http://lists.oasis-open.org/archives/xliff-comment/200807/msg00000.html
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]