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: 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"
">
   <tek:header>The First Volume of Software Structures</tek:header>
   <file original="String" source-language="en-us" datatype="plaintext" date="2001-12-17T09:30:47-05:00" xml:space="default" category="String" target-language="en-us" product-name="String" product-version="String" build-num="String">

 

The specification defines the <xliff> element contents as:

One or more <file> elements, followed by
Zero, one or more non-XLIFF elements.

 

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]