OASIS XML Localisation Interchange File Format (XLIFF) TC

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 currently lives in the c' src= gifBJSSG1QvoG.gif width=16 height=16 wbeuser= rmraya@maxprograms.com > 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

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  

Hi David,   We have a draft in PDF and HTML format and also two schemas in our SVN repository. One schema contains the core and the other the glossary module. The glossary module is documented in an annex of the specification, separated from the core.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of David Walters Sent: Friday, May 04, 2012 12:51 PM To: Rodolfo M. Raya Cc: XLIFF TC Subject: RE: [xliff] Extensibility methods   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  

So all of these elements, along with these inline elements ( <cp> , <ph> , <pc> , <sc> , <ec>, <mrk> . ) are currently defined as "core"? <xliff> 1 +---<file> +            +---<skeleton> ?            +---<unit> +                     +---<segment> +                            +---<source> 1                            +---<target> ?                            +---<notes> ?                                    +---<simpleNote> +                            +---<matches> ?                                     +---<match> +                                                +---<source> 1                                                +---<target> 1                                                +---<originalData> ?                                                         +---<data> +                     +---<ignorable> *                            +---<source> 1                            +---<target> ?                     +---<notes> ?                            +---<simpleNote> +                     +---<matches> ?                            +---<match> +                                     +---<source> 1                                     +---<target> 1                                     +---<originalData> ?                                                +---<data> +                     +---<originalData> ?                                +---<data> +           <cp> , <ph> , <pc> , <sc> , <ec> and <mrk> . The elements 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 12:24:47 PM---Hi David, From: "Rodolfo M. Raya" <rmraya@maxprograms.com> To: <xliff@lists.oasis-open.org> Date: 05/04/2012 12:24 PM Subject: RE: [xliff] Extensibility methods Sent by: <xliff@lists.oasis-open.org> Hi David,   We have a draft in PDF and HTML format and also two schemas in our SVN repository. One schema contains the core and the other the glossary module. The glossary module is documented in an annex of the specification, separated from the core.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From:  xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of David Walters Sent:  Friday, May 04, 2012 12:51 PM To:  Rodolfo M. Raya Cc:  XLIFF TC Subject:  RE: [xliff] Extensibility methods   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  

Yes David. Currently anything core is define here: http://tools.oasis-open.org/version-control/svn/xliff/trunk/schemas/xliff_core_2.0.xsd   -ys   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of David Walters Sent: Friday, May 04, 2012 12:13 PM To: Rodolfo M. Raya Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] Extensibility methods   So all of these elements, along with these inline elements ( <cp> , <ph> , <pc> , <sc> , <ec>, <mrk> .) are currently defined as "core"? <xliff> 1 +---<file> +            +---<skeleton> ?            +---<unit> +                     +---<segment> +                            +---<source> 1                            +---<target> ?                            +---<notes> ?                                    +---<simpleNote> +                            +---<matches> ?                                     +---<match> +                                                +---<source> 1                                                +---<target> 1                                                +---<originalData> ?                                                         +---<data> +                     +---<ignorable> *                            +---<source> 1                            +---<target> ?                     +---<notes> ?                            +---<simpleNote> +                     +---<matches> ?                            +---<match> +                                     +---<source> 1                                     +---<target> 1                                     +---<originalData> ?                                                +---<data> +                     +---<originalData> ?                                +---<data> +           <cp> , <ph> , <pc> , <sc> , <ec> and <mrk> . The elements 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 12:24:47 PM---Hi David, From: "Rodolfo M. Raya" < rmraya@maxprograms.com > To: < xliff@lists.oasis-open.org > Date: 05/04/2012 12:24 PM Subject: RE: [xliff] Extensibility methods Sent by: < xliff@lists.oasis-open.org > Hi David,   We have a draft in PDF and HTML format and also two schemas in our SVN repository. One schema contains the core and the other the glossary module. The glossary module is documented in an annex of the specification, separated from the core.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From:   xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of David Walters Sent:  Friday, May 04, 2012 12:51 PM To:  Rodolfo M. Raya Cc:  XLIFF TC Subject:  RE: [xliff] Extensibility methods   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  

Hi David, Rodolfo, all, > 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. I agree too that it should be in a separate module. I'm certainly no expert in XML Schema, and I may be wrong, but we should be able to use types of the XLIFF core into other modules. Complex types can be used recursively, so I don't see why they could not be used recursively across namespaces as well. If I declare <matches> and <match> in a separate XSD module, using a reference to the source, target and originalData types declared in the core, like this: <xs:element name="match"> <xs:complexType> <xs:sequence> <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/> <xs:element minOccurs="1" maxOccurs="1" ref="xlf:target"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:originalData"/> </xs:sequence> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="origin" use="optional"/> <xs:attribute name="matchquality" use="optional" type="xs:integer"/> </xs:complexType> </xs:element> And in the core module do this: <xs:element name="segment"> <xs:complexType> <xs:sequence> <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:target"/> <xs:element minOccurs="0" maxOccurs="1" ref="xlf:notes"/> <xs:element minOccurs="0" maxOccurs="1" ref="m:matches"/> </xs:sequence> <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> <xs:attribute name="translate" type="xlf:yesNo" default="yes"/> <xs:attribute name="approved" type="xlf:yesNo" default="no"/> </xs:complexType> </xs:element> Everything seems to be ok. And when I have an XLIFF document like this: <xliff version='2.0' xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:m="urn:oasis:names:tc:xliff:matches:2.0" srcLang='en'> <file> <unit id='1'> <segment> <source>text</source> <m:matches> <m:match> <source>text</source> <target>target</target> </m:match> </m:matches> </segment> </unit> </file> </xliff> It seems to work fine and pass validation as well. I've attached the three files. Am I missing something? Cheers, -yves Attachment: MatchModuleTest.zip Description: Zip compressed data

Hi Yves, You commented out the declaration of namespaces in your schemas: <!-- <xs:import namespace=" http://www.w3.org/XML/1998/namespace" ; schemaLocation=" http://www.w3.org/2001/xml.xsd"/ > --> If you restore the declaration, you will see that your schemas are not valid. You cannot include the matches module in the core schema and then try to include the core schema in the matches module. Circular references are not valid when working with XML schemas. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com Maxprograms http://www.maxprograms.com > -----Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: Friday, May 04, 2012 5:39 PM > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] Extensibility methods > > Hi David, Rodolfo, all, > > > 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. > > I agree too that it should be in a separate module. > > I'm certainly no expert in XML Schema, and I may be wrong, but we should > be able to use types of the XLIFF core into other modules. Complex types can > be used recursively, so I don't see why they could not be used recursively > across namespaces as well. > > If I declare <matches> and <match> in a separate XSD module, using a > reference to the source, target and originalData types declared in the core, > like this: > > <xs:element name="match"> > <xs:complexType> > <xs:sequence> > <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/> > <xs:element minOccurs="1" maxOccurs="1" ref="xlf:target"/> > <xs:element minOccurs="0" maxOccurs="1" ref="xlf:originalData"/> > </xs:sequence> > <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> > <xs:attribute name="origin" use="optional"/> > <xs:attribute name="matchquality" use="optional" type="xs:integer"/> > </xs:complexType> > </xs:element> > > And in the core module do this: > > <xs:element name="segment"> > <xs:complexType> > <xs:sequence> > <xs:element minOccurs="1" maxOccurs="1" ref="xlf:source"/> > <xs:element minOccurs="0" maxOccurs="1" ref="xlf:target"/> > <xs:element minOccurs="0" maxOccurs="1" ref="xlf:notes"/> > <xs:element minOccurs="0" maxOccurs="1" ref="m:matches"/> > </xs:sequence> > <xs:attribute name="id" use="optional" type="xs:NMTOKEN"/> > <xs:attribute name="translate" type="xlf:yesNo" default="yes"/> > <xs:attribute name="approved" type="xlf:yesNo" default="no"/> > </xs:complexType> > </xs:element> > > Everything seems to be ok. > > And when I have an XLIFF document like this: > > <xliff version='2.0' xmlns="urn:oasis:names:tc:xliff:document:2.0" > xmlns:m="urn:oasis:names:tc:xliff:matches:2.0" > srcLang='en'> > <file> > <unit id='1'> > <segment> > <source>text</source> > <m:matches> > <m:match> > <source>text</source> > <target>target</target> > </m:match> > </m:matches> > </segment> > </unit> > </file> > </xliff> > > It seems to work fine and pass validation as well. > > I've attached the three files. > Am I missing something? > > Cheers, > -yves

Hi Rodolfo, David, all > You commented out the declaration of namespaces > in your schemas: > <!-- <xs:import namespace=" http://www.w3.org/XML/1998/namespace" ; > schemaLocation=" http://www.w3.org/2001/xml.xsd"/ > --> > If you restore the declaration, you will see > that your schemas are not valid. This import is commented out because xml.xsd doesn't need to be imported in the module: None of the attributes defined in xml.xsd is used directly in <matches> or <match>. > You cannot include the matches module in the core schema > and then try to include the core schema in the matches > module. Circular references are not valid when working > with XML schemas. From what I read it seems that circular references are valid. See for example this answer: http://lists.w3.org/Archives/Public/xmlschema-dev/2005May/0061.html: <cite> Yes, it is allowed. You must import a namespace if you refer to any components in that namespace, and it's certainly allowed for A to reference components in B while B refers to components in A. </cite> And it certainly seems to be working: I can validate documents using those three XSD schemes. For example I can change matchQuality to be required and I get the expected error for the test file. And that works with the two validators I've used. Maybe we can verify the schemes with a few XML Schema experts. If it is possible to have <matches> in its own module that would be better: We should follow our own rules on what is core or module. Cheers, -yves

> -----Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: Sunday, May 06, 2012 9:18 PM > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] matches as a module > > Hi Rodolfo, David, all > > > You commented out the declaration of namespaces in your schemas: > > <!-- <xs:import namespace=" http://www.w3.org/XML/1998/namespace" ; > > schemaLocation=" http://www.w3.org/2001/xml.xsd"/ > --> If you restore > > the declaration, you will see that your schemas are not valid. > > This import is commented out because xml.xsd doesn't need to be imported > in the module: None of the attributes defined in xml.xsd is used directly in > <matches> or <match>. Hi Yves, We use "xml:lang" and "xml:space" attributes from the "namespace" schema in <source> and <target>. These two elements appear inside <match>. We might be able to skip the import in the module but not in the core schema (you commented it out in the core schema too) because <source> and <target> are defined there. I need to check further. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com Maxprograms http://www.maxprograms.com

Good morning Rodolfo, > We use "xml:lang" and "xml:space" attributes > from the "namespace" schema in <source> and <target>. > These two elements appear inside <match>. > We might be able to skip the import in the module > but not in the core schema (you commented it out > in the core schema too) because <source> and <target> > are defined there. I need to check further. Correct: I commented out the wrong import. It should definitely be in core schema. But it doesn't need to be in matches.xsd (as <source> and <target> are not defined there, just referenced). And as long as it's not in both it seems to work. Cheers, -yves

Hi All, I believe that the circular references are legal in XML Schema. To test this I built a small infinite recursion test where you can alternate between namespaces. I also included the "xml" namespace and lang attribute to make sure that can be used from both schemas and namespaces at the same time. You need to properly set up catalogs or have tools that have their own catalogs for this to work well. I tested validation using xmllint and XML Validator Buddy and both worked and did proper validation in the nested namespaces. Regards, Fredrik Estreen > -----Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: den 7 maj 2012 13:07 > To: 'Rodolfo M. Raya'; xliff@lists.oasis-open.org > Subject: RE: [xliff] matches as a module > > Good morning Rodolfo, > > > We use "xml:lang" and "xml:space" attributes > > from the "namespace" schema in <source> and <target>. > > These two elements appear inside <match>. > > We might be able to skip the import in the module > > but not in the core schema (you commented it out > > in the core schema too) because <source> and <target> > > are defined there. I need to check further. > > Correct: I commented out the wrong import. It should definitely be in core > schema. But it doesn't need to be in matches.xsd (as <source> and <target> > are not defined there, just referenced). > > And as long as it's not in both it seems to work. > > Cheers, > -yves > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: xliff-help@lists.oasis-open.org > <?xml version="1.0" encoding="utf-8"?> <circulara xmlns=" http://www.example.com/circular-a" ; xmlns:ca=" http://www.example.com/circular-a" ; xmlns:xml=" http://www.w3.org/XML/1998/namespace" ; xml:lang="en-us" foo="hello"> <cb:circularb xmlns:cb=" http://www.example.com/circular-b" ; xml:lang="fr-fr" bar="hello"> <ca:circulara xml:lang="en-us"> Some text in inner A </ca:circulara> Some text in outer B </cb:circularb> Some text in outer A </circulara> <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" http://www.w3.org/2001/XMLSchema" ; xmlns:xml=" http://www.w3.org/XML/1998/namespace" ; xmlns:ca=" http://www.example.com/circular-a" ; xmlns:cb=" http://www.example.com/circular-b" ; targetNamespace=" http://www.example.com/circular-a" ; elementFormDefault="qualified"> <import namespace=" http://www.w3.org/XML/1998/namespace" ; schemaLocation=" http://www.w3.org/2001/xml.xsd"/ > <import namespace=" http://www.example.com/circular-b" ; schemaLocation="cb.xsd" /> <element name="circulara" type="ca:cat"/> <complexType name="cat" mixed="true"> <sequence> <element ref="cb:circularb" minOccurs="0"/> </sequence> <attribute ref="xml:lang" use="required" /> <attribute name="foo" type="string" use="optional"/> </complexType> </schema> <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" http://www.w3.org/2001/XMLSchema" ; xmlns:xml=" http://www.w3.org/XML/1998/namespace" ; xmlns:ca=" http://www.example.com/circular-a" ; xmlns:cb=" http://www.example.com/circular-b" ; targetNamespace=" http://www.example.com/circular-b" ; elementFormDefault="qualified"> <import namespace=" http://www.w3.org/XML/1998/namespace" ; schemaLocation=" http://www.w3.org/2001/xml.xsd"/ > <import namespace=" http://www.example.com/circular-a" ; schemaLocation="ca.xsd"/> <element name="circularb" type="cb:cbt"/> <complexType name="cbt" mixed="true"> <sequence> <element ref="ca:circulara" minOccurs="0"/> </sequence> <attribute ref="xml:lang" use="required" /> <attribute name="bar" type="string" use="optional"/> </complexType> </schema>

> -----Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Estreen, Fredrik > Sent: Monday, May 07, 2012 12:41 PM > To: Yves Savourel; 'Rodolfo M. Raya'; xliff@lists.oasis-open.org > Subject: RE: [xliff] matches as a module > > Hi All, > > I believe that the circular references are legal in XML Schema. To test this I > built a small infinite recursion test where you can alternate between > namespaces. I also included the "xml" namespace and lang attribute to make > sure that can be used from both schemas and namespaces at the same time. > You need to properly set up catalogs or have tools that have their own > catalogs for this to work well. Hi, I did a test before and even committed to SVN a version of the schemas that had <matches> as a module. It partially worked well with a catalog but when I tested different scenarios there were some problems and I moved things back to their original design. I prefer to have <matches> as a module and use a catalog (we already have a catalog in SVN for handling the glossary module). Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com Maxprograms http://www.maxprograms.com