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


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




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