RE: [xliff] Implementing extensions

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hi Yves,

I understand most of your comments. But I could use further explanation on a couple (see below):

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Monday, April 09, 2012 7:31 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Implementing extensions

Following on Rodolfo's notes about the need for schema:


> I've seen files rejected for these reasons:
> - because the order of attributes in a custom element is different 
> than what the tool expected

XML validation will not resolve this issue. If a given XLIFF tool cannot deal with the XML feature that attributes order does not matter XLIFF should not take the blame for it. The tool is to blame.
In other words: neither custom namespaces nor <metaHolder>/<meta> will solve this.
[Bryan: how does <metaHolder> not help this? Rodolfo says order of attributes causes the rejection. In this case metadata would be not held in attributes, but rather in elements. I think attributes go away - problem goes away.]


> - because a custom element was not updated at translation time

Same here: XML validating won't resolve this.
Processing expectations cannot be validated by schemas.
In other words: neither custom namespaces nor <metaHolder>/<meta> will solve this.


> - because the program expected a custom element that is missing

Validation against a schema certainly helps here.
But validating <meta> will not help because <metaHolder>/<meta> has no information about what data should be there. Only the schema of a custom namespace will solve this.
[Bryan: My thickness causes me to not understand this statement. <meta>/<metaHolder> will be parse-able according to the XLIFF extension schema. What information is needed about what data should be there?]

> Looking from another angle, our work is released under Royalty Free an 
> RAND terms. I would like that any extension to our work be released 
> under the same terms.

Me too. But there is nothing in the licensing of XLIFF that force anyone to do this.

I completely agree with you that we should push any extensions to be public and documented, so they can be validated and used properly. But we can't force it.

Cheers,
-yves



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org