OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only

  • 1.  RE: [xliff] Extensibility methods

    Posted 05-03-2012 17:30
        Hi Yves,   FWIW, <matches> currently lives in the core, not in a module. It cannot be in a module because it depends on core elements, like <source>, <target> and inline elements.  It could be moved to a module if we define elements that duplicate the functionality of <source>, <target> and all inline codes. Notice, however, that <matches> is an optional element and is not required when the XLIFF file is created; it can be added (or not) after creating the XLIFF document.   The only module we have defined so far is the one that handles glossaries.   Data from an XLIFF module is optional. A module is defined as something not required to create an XLIFF file, translate it and generate a translated document.  A tool that doesn't know how to use optional module data can safely ignore it and doesn't have to maintain it. Such tool may even delete module data, as it is not required for generating a translated document.   If you enhance an XLIFF file by adding <glossary> elements, the user can take advantage of that data by using a tool that supports it. If the user prefers to work with a tool that cannot handle <glossary>, that doesn't interfere with the translation process and the generation of a translated document. The tool may safely delete <glossary> elements and nothing will be damaged. It would be nice if tools preserve module data, but that is not a requirement.   Things that must be preserved by all tools should be part of the XLIFF core and have precise processing expectations. Even optional core elements, like <matches>, should have processing expectations that indicate whether they can be removed or not.   Anything not specified in the XLIFF core is by definition not essential for completing the translation cycle. In other words, disposable.   Regards, Rodolfo -- Rodolfo M. Raya Maxprograms http://www.maxprograms.com    


  • 2.  RE: [xliff] Extensibility methods

    Posted 05-03-2012 17:39




    Hi Yves, Rodolfo,
     
    I would say that the rule for <segment> and <ignorable> should be that if the segment is merged or split an application:
    * MUST remove any non-core elements and attributes it does not support.
    * MAY remove any non-core elements and attributes.
    from the affected <segment> and <ignorable> elements.
     
    This probably hold for other places as well. It allows an application to preserve as much data as it can and if it cannot determine if it is safe
    it must remove the data. Since it is optional data that should not be an issue. I think we should decide on this type of expectation whenever a module add constructs on top of core and define the expectation in core.
     
    Regards,
    Fredrik Estreen
     


    From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
    On Behalf Of Rodolfo M. Raya
    Sent: den 3 maj 2012 19:30
    To: Yves Savourel; XLIFF TC
    Subject: RE: [xliff] Extensibility methods


     

     


     


    Hi Yves,


     


    FWIW, <matches> currently lives in the core, not in a module. It cannot be in a module because it depends on core elements, like <source>, <target> and inline
    elements.  It could be moved to a module if we define elements that duplicate the functionality of <source>, <target> and all inline codes. Notice, however, that <matches> is an optional element and is not required when the XLIFF file is created; it can be
    added (or not) after creating the XLIFF document.


     


    The only module we have defined so far is the one that handles glossaries.


     


    Data from an XLIFF module is optional. A "module" is defined as something not required to create an XLIFF file, translate it and generate a translated document.
     A tool that doesn't know how to use optional module data can safely ignore it and doesn't have to maintain it. Such tool may even delete module data, as it is not required for generating a translated document.


     


    If you enhance an XLIFF file by adding <glossary> elements, the user can take advantage of that data by using a tool that supports it. If the user prefers to
    work with a tool that cannot handle <glossary>, that doesn't interfere with the translation process and the generation of a translated document. The tool may safely delete <glossary> elements and nothing will be damaged.



    It would be nice if tools preserve module data, but that is not a requirement.


     


    Things that must be preserved by all tools should be part of the XLIFF core and have precise processing expectations. Even optional core elements, like <matches>,
    should have processing expectations that indicate whether they can be removed or not.


     


    Anything not specified in the XLIFF core is by definition not essential for completing the translation cycle. In other words, disposable.


     


    Regards,


    Rodolfo


    --
    Rodolfo M. Raya
    Maxprograms http://www.maxprograms.com


     


     




    Original Message


  • 3.  RE: [xliff] Extensibility methods

    Posted 05-04-2012 14:57
    I do not believe that we have ever clearly defined what is core and what is module.   In my opinion, <matches> would not be core, as it is not required to process an XLIFF file.  A file without <matches> is a perfectly valid XLIFF file for lots of situations.  A development group creating an XLIFF file to hold their English translatable strings has no interest in <matches> and probably does not even have access to that information. Just because it has dependencies on <source> and <target> does not require it to be core. David Corporate Globalization Tool Development EMail:  waltersd@us.ibm.com           Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721 CHKPII:                     http://w3-03.ibm.com/globalization/page/2011 TM file formats:     http://w3-03.ibm.com/globalization/page/2083 TM markups:         http://w3-03.ibm.com/globalization/page/2071 "Rodolfo M. Raya" ---05/03/2012 12:32:46 PM---    Hi Yves,   FWIW, <matches> currently lives in the core, not in a module. It cannot be in a modul From: "Rodolfo M. Raya" <rmraya@maxprograms.com> To: "Yves Savourel" <ysavourel@enlaso.com>, "XLIFF TC" <xliff@lists.oasis-open.org> Date: 05/03/2012 12:32 PM Subject: RE: [xliff] Extensibility methods Sent by: <xliff@lists.oasis-open.org>     Hi Yves,   FWIW, <matches> currently lives in the core, not in a module. It cannot be in a module because it depends on core elements, like <source>, <target> and inline elements.  It could be moved to a module if we define elements that duplicate the functionality of <source>, <target> and all inline codes. Notice, however, that <matches> is an optional element and is not required when the XLIFF file is created; it can be added (or not) after creating the XLIFF document.   The only module we have defined so far is the one that handles glossaries.   Data from an XLIFF module is optional. A "module" is defined as something not required to create an XLIFF file, translate it and generate a translated document.  A tool that doesn't know how to use optional module data can safely ignore it and doesn't have to maintain it. Such tool may even delete module data, as it is not required for generating a translated document.   If you enhance an XLIFF file by adding <glossary> elements, the user can take advantage of that data by using a tool that supports it. If the user prefers to work with a tool that cannot handle <glossary>, that doesn't interfere with the translation process and the generation of a translated document. The tool may safely delete <glossary> elements and nothing will be damaged. It would be nice if tools preserve module data, but that is not a requirement.   Things that must be preserved by all tools should be part of the XLIFF core and have precise processing expectations. Even optional core elements, like <matches>, should have processing expectations that indicate whether they can be removed or not.   Anything not specified in the XLIFF core is by definition not essential for completing the translation cycle. In other words, disposable.   Regards, Rodolfo -- Rodolfo M. Raya Maxprograms http://www.maxprograms.com    
    Original Message


  • 4.  RE: [xliff] Extensibility methods

    Posted 05-14-2012 16:41
    Hi all, R> It would be nice if tools preserve module data, R> but that is not a requirement. R> ... R> Anything not specified in the XLIFF core is by R> definition not essential for completing the R> translation cycle. In other words, disposable. The reason why I digressed into modules in my argument about using custom namespaces for extensions is that both are about using namespaces and how tools that don't support those namespaces have to handle them. For all its short-comings 1.2 was at least providing a way to get all XLIFF features across a process. With 2.0 if only the core is guaranteed to be passed from tool to tool, we are in fact restricting true interoperability to only what goes in the core (basically: extracting source and merging translation). I think an important aspect of interoperability is that tool not supporting a given module still should preserve pass its elements/attributes through to the next tool. While I do understand that some tools may not be able to do so, we should still make sure the specification issues a very strong recommendation that preserving un-supported data is important. For example I would see a processing expectation saying "Tools that do not support a module SHOULD nevertheless preserve its elements and attributes" rather than something like: "Any element or attribute of an optional module MAY be removed by the tools that do not support that module". We allow removal in both cases, but it is clear that *not removing* is the default expected behavior. A big caveat here is that there will be cases where removal of some elements may be the expected behavior (e.g. maybe when re-segmenting, etc. as Fredrik pointed out), and that is something we should specify on a case-by case for each module. Now, to get back to the initial topic: extensions. If we do have an expected behavior that favors preserving un-supported official modules, tools can use the same mechanism they use for doing this to also handle extensions implemented as custom namespaces. If we use an optional module like <metaHolder> for extensions, we will get tools that supports <metaHolder> (to store their own extensions), but do not implement the other official modules. So we will end up with tools that preserve custom extensions but not other official modules. Somehow we'll manage to allow better handling of user extensions than official modules. That doesn't sound like a result we want. My point is: Yes, namespaces are hard to implement. But we do use them for modules. So there is no reason they wouldn't work for extensions as well. F> The first thing is a point which I don't think has F> been discussed before, and that is how easy it F> would be for a tool to make meaningful use of unknown F> extension data. At first it might sound like a F> nonworking or bad idea but I think there are cases F> where it would add value. In many cases metadata could F> be made useful even if the tools do not know the F> exact meaning of it, the problem is finding a good F> way to present it to the user. Here I believe that F> <metaHolder> as a grouped key/value store is much simpler F> to work with than arbitrary XML in a namespace. That is true: metaHolder has probably more advantages for tools not understanding the extensions stored in metaHolder. But the problem is that metaHolder is less practical than namespaces for the tools that do know about the given extensions. So we would be making things more difficult for all users of extensions, so that tools not using those extensions may or may not somehow do something with data they don't support? I think restricting XLIFF to a dumb-down extension capability is not good for the future. As Paul Leahy noted in one of his presentations on XLIFF, it's important that XLIFF 2.0 can evolve, and custom namespace are perfect as stepping stones to new official modules. I think we should let users define how best their extensions can be implemented, **as long as they stay in a clear set of restrictions**. And those restrictions, let's remember, must be define even if we go with <metaHolder>. Cheers, -yves


Related Content