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] Conformance clause proposal

Hi Rodolfo,

Thanks for your comments. See my replies inline below.

----- "Rodolfo M. Raya" <rmraya@maxprograms.com> wrote:
> Suppose that tool ABC creates XLIFF files with custom extensions. 
> John Translator receives one of those files and translates using XYZ.
> When he delivers the translated file, the client says that it is
> invalid because ABC can't open it. Common case today.
> The maker of XYZ could use the schemas from ABC to ensure
> compatibility. Validating the file could reduce the number of errors
> caused by misinterpreted custom elements. This will not solve all
> problems, but will help.

Yes, but I don't think - from a standards point of view - the best solution here is to make the foreign schemas publicly available. Tool maker XYZ should not have to understand or process extensions in XLIFF files from tool ABC in order to process the XLIFF document. That would allow tools that previously conformed to the standard to suddenly become break because they don't understand a newly published extension. The XLIFF specification should outline processing expectations for foreign elements and attributes, in essence ignoring but preserving elements and attributes it does not understand. If these expectations cannot be practically implemented, we need to review and look at restricting the extension points we have in XLIFF 1.2.

Further, publishing all third party extensions requires some public Oasis-blessed repository of schema extensions that is updated after the standard is released. I don't think this is realistic beyond publishing as part of XLIFF 2.0 the core XLIFF schema and schemas for other core XLIFF extensions we define as part of the specification.

> There are cases when we don't have a solution. For example, there is a
> tool in the market today that doesn't read its own XLIFF files as XML.
> It fails in these two cases:
> 1) if you change this:
>       <?xml version="1.0" encoding="UTF-8"?><xliff ....
> to: 
>       <?xml version="1.0" encoding="UTF-8"?>
>       <xliff ....
> that tool says that it is not valid XLIFF.
> 2) If XYZ changes the order of attributes in an element, the tool
> can't generate a translated document. It complains about an error in
> the file.

This sort of problems is out of scope for the technical committee. Even the most basic conformance clause will catch these sort of issues. 

> There is another tool that uses custom namespaces for moving
> attributes to different places. For example, it puts the status of a
> translation in <trans-unit> instead of <target> and puts the match
> quality value in <trans-unit> instead of <alt-trans>. If their custom
> schemas were public, third party tools would be able to set the
> attribute values.

I like the way e.g. ODF restricts the use of extensions to features that is not specified by the specification, we should include something like that. That said, part of the 'extension eco-system' we hope to see in XLIFF 2.x will of course need public schemas and specifications that tools can implement. I'm not arguing against that, I'm just saying it shouldn't be part of the conformance clause.

The more interesting question is perhaps if we should allow extensions that prevents clients from changing an XLIFF file if they do not know how to process the extension, something similar to the 'mustUnderstand' attribute in SOAP [1]. But I'm quite sceptical to this approach as well, as it will hurt interoperability.

> We can't solve all interoperability problems, but we can try to reduce
> them. Making schemas public would help other tool vendors.
> XLIFF is an open standard promoting open exchange. We should not allow
> secrets that damage XLIFF's openness for exchanging localization data.

It's a good goal, I agree. But I don't think it's practically feasible in terms of XML processing. We should of course encourage public schemas as well as documentation of the processing expectations for specific third party extensions, but enforcing this on the standard-level is not possible or desirable in my opinion.


[1] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383500

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