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: Problems with official XLIFF samples and Transitional schema

Hi Rodolfo and Doug,

I'm going to try to give my opinion on all the issues that arose in this thread (and I'm also going to go ahead and cc the list - again, to be transparent and to welcome other opinions). Readers should know that parts of this thread are left out (due to the evolution of the thread), and can be resurrected if necessary.

1. Fixed sample files: I looked at the new sample files and I agree that they should be posted in place of the samples that do not accurately fit the commentary in the spec.

2. Problems in the schemas
 a. The trans-unit accidentally includes the merged-trans attribute, should we fix the schemas? In my opinion, this is not a showstopper and can be fixed in the XLIFF 2.0 schemas.
 b. Transitional schema allows lax processing of namespace attributes
(<xsd:anyAttribute namespace="##any" processContents="lax"/>), which allows seemingly invalid attribute in extensible points (i.e., attributes with non XLIFF names, and no namespace): In my opinion this might be okay. This seems like it could have to do with the "art" of XML validation vs. the "science." If we set it to strict, we require a schema to be included with each extensible attribute. Sounds okay in theory, but because we have so little control of the schemas in the world, and because schemas are (believe it or not) very difficult to write in such a way that they make attributes even able to be valid in contexts they are "leant" to, it can be a nightmare (I have plenty of war stories on this topic).
 c. Schemas do not enforce bx and ex, or bpt and ept id pairing: I think this would be difficult to enforce with a schema (trying in my head to imagine how to express that). It is also tricky because the spec says that the paired elements should be related via the rid attributes. And *only in the absence of rid attributes (my words)* the id attribute should be used to match the pair. The spec then goes on to prescribe a different purpose for id attributes that would not at all require them to relate the pairs (i.e., the id attribute  is used to reference replaced code in the skeleton file).

I guess one of the things we (and most TCs) concede is that we want the schemas to enforce as much of the spec as is possible or practical, but we realize some nuances cannot be controlled by the schema - and are expressed in the spec. My own personal opinion is that even some scenarios that a schema can enforce, through extremely complex regex and elegance, should be balanced against the degree to which that complexity and difficulty penalizes human schema readers and maintainers.



-----Original Message-----
From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com]
Sent: Monday, June 22, 2009 5:05 AM
To: Doug Domeny
Cc: Tony Jewtushenko; Schnabel, Bryan S
Subject: Re: Problems with official XLIFF samples and Transitional schema

On Thu, 18 Jun 2009 07:57:52 -0400
"Doug Domeny" <ddomeny@ektron.com> wrote:

> I agree with improving the samples, but I don't think we should change
> the transitional schema. In the sample there is a bx and ex, but
> perhaps they are not correctly associated. What is the suggested fix?


That attached zip file contains updated samples that the latest version
of XLIFFChecker (released yesterday) considers acceptable.

The original samples have these problems:

 * Wrong values in "date" attributes (recommended ISO format not
 * <bpt>/<ept> elements not paired correctly.
 * <bx/>/<ex/> elements not paired correctly.
 * <it> elements without corresponding pair within <file>
 * Language mismatches: <source> elements with "xml:lang" value
   different from the one declared in <file>.
 * Not a bug, but bad practice: incorrect ISO format for language codes
   ("en-us" instead of "en-US").

Rodolfo M. Raya <rmraya@maxprograms.com>
Maxprograms http://www.maxprograms.com


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