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: RE: [xliff-comment] XLIFF 1.2 errata, questions and comments

Hi Christian,

I regret that I have been on a short vacation until today, and that Stefan Uhrig has not gotten a reply to his thoughtful post.  I will try to get back on my feet, here in the office, and see that he gets a proper response as soon as possible. At least I will send a note to him letting us know we are working on a response, and not ignoring his comment.

As for your question about the spec trumping the schema when there are differences, I think that is a good rule.  This one of the reasons I'd really like to get an official working draft version of XLIFF 2.0 passed and posted.  Not only would it be a start for the new features we're developing, it would also give us an "official" place to post fixed versions of the XSD that Doug has been quick to make.  I will propose to the TC that we make penning and passing a working draft, along with working draft XSDs a TOP priority.



-----Original Message-----
From: Lieske, Christian [mailto:christian.lieske@sap.com]
Sent: Monday, July 21, 2008 9:17 AM
To: Schnabel, Bryan S
Subject: RE: [xliff-comment] XLIFF 1.2 errata, questions and comments

Hi Bryan,

I wonder if OASIS or the TC has a kind of general rule such as "If XSD
and Spec. differ, then the Spec. wins".


-----Original Message-----
From: Uhrig, Stefan [mailto:stefan.uhrig@sap.com]
Sent: Monday, July 14, 2008 3:13 PM
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
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
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
"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
either exactly one <internal-file> or one <external-file> element".
the schema allows either exactly one <internal-file> or one
element only, but no reference material description.

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

Section 3.2.2:

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

According to specification in element <count> the attribute "count-type"
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
revised XLIFF 1.2 specification?

Additionally I came across some ambiguities, especially typing of
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
an integer type (like for minbytes and maxbytes). However, the schema
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 typing?

On attribute "coord" the specification states that cx and cy represents
width and height as in Windows resources. The schema allows signed
for cx and cy. However, the Windows resource specification
(http://msdn.microsoft.com/en-us/library/ms907882.aspx) states that
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.
the schema allows values that are not valid according to RFC 1341 (e.g.
"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
by XLIFF-schema (for example "X-test/test"). Furthermore: while there is
some pattern-typing for attribute "mime-type", the related attribute
is not typed this way. Is there a reason why "mime-type" and "form" are
required to correspond exactly to RFC 1341?

Regarding attributes "minbytes" and "maxbytes" the specification states
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
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
interchangeability in a negative way as implementers will do that in
different incompatible ways. What is the correct way to evaluate these

Best Regards,
Stefan Uhrig

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