RE: [xliff] Extensibility methods

[David Walters <waltersd@us.ibm.com>]

Do we have a running list of element and attributes which are core and which are considered modules?

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/04/2012 10:15:10 AM---Hi David,   We defined core and module, conducted a ballot and approved both definitions. They are i

From: "Rodolfo M. Raya" <rmraya@maxprograms.com>
To: "XLIFF TC" <xliff@lists.oasis-open.org>
Date: 05/04/2012 10:15 AM
Subject: RE: [xliff] Extensibility methods
Sent by: <xliff@lists.oasis-open.org>

---

Hi David,
 
We defined core and module, conducted a ballot and approved both definitions. They are included in the specification draft.
I agree with you, <matches should live in a module and I tried to move it to a module. Unfortunately, <matches> content is too related to <source> and <target> and we cannot separate <matches> from the rest using namespaces. 
 
Regards,
Rodolfo
--
Rodolfo M. Raya 
Maxprograms http://www.maxprograms.com

-------- Original Message --------
Subject: RE: [xliff] Extensibility methods
From: David Walters <waltersd@us.ibm.com>
Date: Fri, May 04, 2012 11:55 am
To: "Rodolfo M. Raya" <rmraya@maxprograms.com>
Cc: "XLIFF TC" <xliff@lists.oasis-open.org>, "Yves Savourel"
<ysavourel@enlaso.com>


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 --------
Subject: RE: [xliff] Extensibility methods
From: Yves Savourel <ysavourel@enlaso.com>
Date: Thu, May 03, 2012 1:38 pm
To: <xliff@lists.oasis-open.org>

Hi all,

I tend to agree with Fredrik's general assessment of metaHolder and custom namespace: one is simpler and can be handled more generically, the other is more powerful but less easy to work with generically.

Now a question (seemingly un-related, but bare with me for a while):

What are the processing expectations for an optional XLIFF module (e.g. like <matches>) for a tool that does not support that module?

Concretely, for example, if Tool A does not support <matches>, is the tool expected to try to preserve it? Is it expected to somehow set some flag on it if the segmentation changes and affect <matches>?

In other words: what type of generic processing do we expect a tool to do on the elements of the XLIFF modules it does not support?


Cheers,
-yves



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

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