OASIS XML Localisation Interchange File Format (XLIFF) TC

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. > - 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. > 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

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

Hi Bryan, >>> 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.] If the tool can't deal with re-ordered attributes in custom extensions, it's very likely that it can't deal with them in normal XLIFF elements either. The problem here is not specifically related to custom extension. In any case: we shouldn't try to design XLIFF based on the fact that some tool does not use an XML parser to read an XLIFF file. XML/XLIFF attributes can be in any order and the tools must support that. >>> - 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?] The schema for the XLIFF metadata can only state how <metaHolder>/<meta> are define. For example that the content of <meta> is a string. For example <m:meta key="number-of-words">2</m:meta> will be valid. But <m:meta key="number-of-words">schtroumpf</m:meta> will also be valid. If we really want to *validate* the custom data you need a schema that says the data associated with number-of-words is of type number not string. Validating against the schema a generic XLIFF metadata namespace is going to be too generic to be meaningful. Worst: now because the users would have to use that XLIFF namespace, they would have no schema-based way to truly validate their custom data. -ys