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


Rodolfo,

Very well explained, and thank you for clarifying the difference between the 'conformance clause' and general processing expectations of the format. 

We should make use of the standard 'ISO/IEC Directives' terminology ('should 'must' 'must not' etc) in defining the processing expectations for each feature within the specification.

Here's a good example of a conformance clause:
http://docs.oasis-open.org/office/v1.2/part1/cd04/OpenDocument-v1.2-part1-cd04.html#a_22_Conformance

And an example of 'Processing Expectations':
http://docs.oasis-open.org/office/v1.2/part1/cd04/OpenDocument-v1.2-part1-cd04.html#a_21_Document_Processing


cheers,
asgeir

----- "Rodolfo M. Raya" <rmraya@maxprograms.com> wrote:

> Hi,
> 
> Interoperability has two outstanding aspects:
> 
> 1) Compliance of XLIFF documents.
> 2) Compatibility in processing.
> 
> With the conformance clause we can set the rules that deal with
> documents and their validity.
> 
> Processing expectations should be included in the specification, next
> to each feature. But we need coherency in the specification.
> 
> Yves' example of support for the "translate" attribute is interesting.
> You can set the value of this attribute in <trans-unit> elements but
> if you use <source-seg> in your XLIFF files, you cannot apply it at
> segment level. This is a problem with the specification that tools
> cannot address.
> 
> A problem I see frequently is related to the "approved" attribute. For
> interoperability, I expect that an XLIFF enabled tool would let the
> user set the value of the "approved" attribute, but the specifications
> don't say anything about it. We can avoid this problem by stating some
> rules in the specification, something along these lines but not
> necessarily this:
> 
>        "When generating the final document, the value of the
> "approved" attribute must be considered. If its 
>        value is "yes", use the translations provided in the <target>
> element. Otherwise, use the text included 
>        in the <source> element."
> 
> By including some text that indicates what to expect considering the
> elements and attributes present in the XLIFF file, we can start
> solving the interoperability between tools. A paragraph like the one
> above will tell the tool maker that something has to be done with the
> "approved" attribute.
> 
> In the same way, the specification could include text like this:
> 
>       "When a translation unit has the "translate" attribute set to
> "no", the content of the unit can be displayed 
>       to the user as context information, but the user must not be
> able to modify the translation unit."
> 
> XLIFF 1.2 allows users to indicate the state of <target>'s content.
> That's valuable information for reviewing a translation, but not all
> tools support setting values for the "state" attribute. The
> specification defines what "state" means, but does not tell
> implementers when and how to use it. Nothing says that when a
> translation has been added to a previously empty target, the state
> should change from "needs-translation" to something else.
> 
> We need to start including in the specs what "XLIFF enabled tools"
> should do with each and every attribute or element we include in the
> specs. If there are no defined expectations for a given element, we
> should consider dropping it.
> 
> Regards,
> Rodolfo
> --
> Rodolfo M. Raya   <rmraya@maxprograms.com>
> Maxprograms      http://www.maxprograms.com
> 
> 
> > -----Original Message-----
> > From: Yves Savourel [mailto:ysavourel@translate.com]
> > Sent: Tuesday, June 01, 2010 2:41 PM
> > To: xliff@lists.oasis-open.org
> > Subject: [xliff] Conformance / Compliance
> > 
> > Hi all,
> > 
> > Very interesting discussion today. Hopefully we can continue on the
> mailing
> > list.
> > 
> > May be there are different aspects to to consider in "compliance".
> > 
> > I agree with Rodolfo that for conformance we can only talk about
> the
> > document. XLIFF has a specification, along with a schema, and a
> document is
> > or not conformant to those. No tools involved. And applications
> like
> > XLIFFChecker can hopefully check that conformance.
> > 
> > But that is only one facet of the compliance problem.
> > 
> > I don't think OASIS has a formal way to handle the other facet:
> processing
> > expectations.
> > And to me that is where the biggest interoperability issue resides.
> > Users don’t care if their document is conformant, they care if their
> tools can
> > read it, work with it, and generates back a file that the initial
> tool can be
> > happy with.
> > 
> > This usually translate into being able to ascertain that a tool uses
> the proper
> > XLIFF construct to act on a given aspect of the document.
> > 
> > For example, in 1.2, there is a translate="yes/no" attribute that
> indicates if
> > the trans-unit content needs to be translated or not. I would expect
> a "XLIFF-
> > compliant" tools to use that attribute to both indicate that status
> of a trans-
> > unit (when generating XLIFF), and to read that information when
> sorting out
> > what is translatable or not in the file (when loading XLIFF).
> > 
> > There has to be ways to prescribe those processing expectations in
> the
> > standard. We are not in the conformance aspect anymore, I agree. But
> this
> > facet is as important to XLIFF as document conformance is, otherwise
> we will
> > keep having documents that are not really seamlessly useable for
> exchange,
> > because the tools pick and choose how they work with the standard.
> > 
> > I don't know how that can be achieved. I think having a much more
> modular
> > XLIFF and stricter modules (e.g. less attr="x-whatever") could help.
> It is a
> > difficult problem, because we need to make sure while the format is
> more
> > strict, the tools still have ways to implement things how it works
> best for
> > them.
> > I feel certain this is an aspect we have to tackle to have a XLIFF
> 2.0 that "really
> > works".
> > 
> > Cheers,
> > -ys
> > 
> > 
> > 
> > 
> > 
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC
> that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-
> > open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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