OASIS XML Localisation Interchange File Format (XLIFF) TC

Back to discussions
Expand all | Collapse all

Namespace in modules

  • 1.  Namespace in modules

    Posted 11-06-2012 21:50
    Hi all, I had the action item to specify a proposal regarding the namespace in modules: === first, some background: Currently the part of the draft defining a module says this: "A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each official module defined for XLIFF 2.0 has its grammar defined in an independent XML Schema with a separate namespace." Based on that: -1 there is no restriction on what the namespace of the module is. -2 It doesn't say you can use several namespaces, like we do with matches or glossary for example (where we use the XML and the core namespaces), so technically we could biker about the existing modules. -3 it doesn't say any think about the version of the core and the modules -4 it doesn't say anything about where modules could be set (so by default that could be anywhere). The immediate concern I have is to make sure the ITS WG can map its metadata to XLIFF. As it stands now, we cannot. To be able to do it we would need either: -A) That the <mrk> element allows extended attributes -B) that we can for sure have a module allowing us to use ITS native markup in <mrk> The solution A) is actually rather logical: <mrk> is where tools annotate the content, there is a limited mechanism in place that allows user-defined metadata to a certain extent, but it a bit like <metadata> for the element: it's not enough in several of our use cases. The main problem with having extension at the segment level is about what to do with the data when re-segmenting. But in the case of <mrk> that problem does not occurs since it's an inline element. But for various reason I think having a module instead is fine, and even probably better as it formalizes things a bit more. So I want to make sure solution B) is doable. That in Dec-2013 when ITS 2.0 becomes a recommendation we can add a new module to XLIFF that simply uses the ITS native attributes. The text we have currently is actually ok to achieve that, but as one could see this morning, that is not necessarily the opinion of everyone. So I want to make sure we have clear rules on how to add/remove modules in XLIFF. === A proposal: So here is a possible text proposal for the section 1.1.3 entry "XLIFF Module". Maybe it should have a separate section, but that is not important: A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can be placed in locations that are not extension points. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF, even if no other part of the specification has changed. -- Either 1: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), from the World Wide Web Consortium (W3C), from the European Telecommunications Standards Institute (ETSI), from ISO, or from the Unicode Consortium. -- Or 2: A module MUST only use namespaces of final specifications. The owners of these namespaces MAY be OASIS or other organizations. === and some comments on the proposal - Adding a modules will require publishing a new version of XLIFF. Which is time consuming. I don't like that at all, but I don't see how otherwise make sure can modules evolve orderly. My concern is how much time will the TC take to add a new module. This is also why I think both module and extensions have the same PRs for core-only tools: this allows time without preventing the extension-moving-to-modules to be impaired. - I understand Fredrik's concern about not allowing "any" namespace as possibly used in extensions, but at the same time having a list is limitative: why only those organizations (whichever they end up being) have that privilege? I'm really wondering if this restriction (the first option) is necessary: the TC is in charge of accepting or not the new modules, so it can refuse anything, including modules namespaces from those organizations. What is important IMO is to state that one cannot refuse a namespace on the ground that only TC-defined namespaces are allowed. I've tried to capture this in the second option. Regards, -yves


  • 2.  RE: [xliff] Namespace in modules

    Posted 11-06-2012 22:06
    Hi Yves, Adding attributes from ITS namespace is one thing and adding ITS native markup is quite different. I don't like the idea of elements defined outside the TC being treated as a module. We cannot accept a module defined on a vague version of a standard. If you want to introduce a schema defined outside XLIFF, you must at least settle on a given version. Converting a custom extension into a module does not require rewriting the XLIFF specification or changing the XLIFF version number. A module can be officially published as a Committee Note. Preparing a Committee Note should not take a long time, it would only depend on the writing speed of the person proposing the module. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com Maxprograms http://www.maxprograms.com >
    Original Message


  • 3.  Re: [xliff] Namespace in modules

    Posted 11-06-2012 23:03
    Rodolfo, Note is not normative. Proper modules will require new 2.x increments. Even if you are adding or removing just one module, you actually must change core specification, if only in a immaterial way. We specify in core where and in what order the modules can occur.. 2.x increments will take time depending on their volume. We must not be afraid of publishing 2.x increments, we introduced modules to make this easier. As P&L SC Chair i understand that public reviews and OASIS ballots will need to be organized repeatedly and am ready to take on the challenge :-) Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Tue, Nov 6, 2012 at 10:05 PM, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi Yves, Adding attributes from ITS namespace is one thing and adding ITS native markup is quite different. I don't like the idea of elements defined outside the TC being treated as a module. We cannot accept a module defined on a vague version of a standard. If you want to introduce a schema defined outside XLIFF, you must at least settle on a given version. Converting a custom extension into a module does not require rewriting the XLIFF specification or changing the XLIFF version number. A module can be officially published as a Committee Note. Preparing a Committee Note should not take a long time, it would only depend on the writing speed of the person proposing the module. Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com >
    Original Message


  • 4.  RE: [xliff] Namespace in modules

    Posted 11-07-2012 12:11
    Hi Rodolfo, all, > We cannot accept a module defined on a vague version of a > standard. If you want to introduce a schema defined outside > XLIFF, you must at least settle on a given version. Who said I wasn't? Maybe you have missed part of the text proposal? It says: "...A module MUST only use namespaces of final specifications..." To me that is not "a vague version". In the case of the module using ITS 2.0, I said we would present it when ITS 2.0 is a W3C Rec. The minutes even recorded that (despite that they are pretty poor minutes): Min> R: standard not finished yet Min> F: but when stable, that's ok Min> Y: will wait for when ITS 2.0 is stable, done. > Adding attributes from ITS namespace is one thing and > adding ITS native markup is quite different. > I don't like the idea of elements defined outside the > TC being treated as a module. If we agree that a module can use attributes from a non-TC namespace (like xml:lang, or its:whatever) then what technical reason we would have to prevent a module to use elements from a non-TC namespace? The TC is in charge of accepting the module or not. If the existing schema is not satisfactory (e.g. it an element that allows any elements itself) the TC can ask the submitter to fix his schema. The TC can make sure everything is under control as if it were defined by the TC, the only difference is it has a non-TC URI. I don't want our XLIFF documents to be a mess either. I just want to make sure the specification explicitly state that modules can be made on non-TC namespaces. Something that is implicitly allowed today. If anything the proposal is more limitative that the current text. > Converting a custom extension into a module does not require > rewriting the XLIFF specification or changing the XLIFF version > number. A module can be officially published as a Committee Note. > Preparing a Committee Note should not take a long time, it > would only depend on the writing speed of the person proposing > the module. To add/remove a module, one has to change the schema of the core. If we change the schema, we change the current version of XLIFF. If we change the version of XLIFF, we have to re-publish. Publishing a Note would make no difference: the core schema has to change. I don't see how that can be done differently, but I may be missing something. Maybe someone for OASIS could help us with this? Regards, -yves


  • 5.  Re: [xliff] Namespace in modules

    Posted 11-06-2012 23:26
    Hi Yves, all, one alternative proposal 3 and a few comments inline.. Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Tue, Nov 6, 2012 at 9:35 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi all, I had the action item to specify a proposal regarding the namespace in modules: === first, some background: Currently the part of the draft defining a module says this: "A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each official module defined for XLIFF 2.0 has its grammar defined in an independent XML Schema with a separate namespace." Based on that: -1 there is no restriction on what the namespace of the module is. -2 It doesn't say you can use several namespaces, like we do with matches or glossary for example (where we use the XML and the core namespaces), so technically we could biker about the existing modules. -3 it doesn't say any think about the version of the core and the modules -4 it doesn't say anything about where modules could be set (so by default that could be anywhere). The immediate concern I have is to make sure the ITS WG can map its metadata to XLIFF. As it stands now, we cannot. To be able to do it we would need either: -A) That the <mrk> element allows extended attributes -B) that we can for sure have a module allowing us to use ITS native markup in <mrk> The solution A) is actually rather logical: <mrk> is where tools annotate the content, there is a limited mechanism in place that allows user-defined metadata to a certain extent, but it a bit like <metadata> for the element: it's not enough in several of our use cases. The main problem with having extension at the segment level is about what to do with the data when re-segmenting. But in the case of <mrk> that problem does not occurs since it's an inline element. But for various reason I think having a module instead is fine, and even probably better as it formalizes things a bit more. I agree that module is better but the first step to that module should be anyway <mrk> and <note> extensibility. As any other new module that is not specified as module outright,  the modules will evolve from broadly adopted extensions. So I want to make sure solution B) is doable. That in Dec-2013 when ITS 2.0 becomes a recommendation we can add a new module to XLIFF that simply uses the ITS native attributes. The text we have currently is actually ok to achieve that, but as one could see this morning, that is not necessarily the opinion of everyone. So I want to make sure we have clear rules on how to add/remove modules in XLIFF. === A proposal: So here is a possible text proposal for the section 1.1.3 entry "XLIFF Module". Maybe it should have a separate section, but that is not important: A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can be placed in locations that are not extension points. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF, even if no other part of the specification has changed. I would remove ", even if no other part of the specification has changed" If nothing else the spec will need to specify place and order of the new module etc.  -- Either 1: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), from the World Wide Web Consortium (W3C), from the European Telecommunications Standards Institute (ETSI), from ISO, or from the Unicode Consortium. -- Or 2: A module MUST only use namespaces of final specifications. The owners of these namespaces MAY be OASIS or other organizations. Alternative proposal 3: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the Inetranational Standards Organization, or the Unicode Consortium. Namespaces of private custom extensions (member submissions) promoted to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces.   === and some comments on the proposal - Adding a modules will require publishing a new version of XLIFF. Which is time consuming. I don't like that at all, but I don't see how otherwise make sure can modules evolve orderly. My concern is how much time will the TC take to add a new module. This is also why I think both module and extensions have the same PRs for core-only tools: this allows time without preventing the extension-moving-to-modules to be impaired. Any extension (including W3C ITS) should be protected by SHOULD rather than MUST until it becomes module, as only the committee process can ensure that it does not have harmful impact, and unlike module it can compete for functionality with other extensions.  - I understand Fredrik's concern about not allowing "any" namespace as possibly used in extensions, but at the same time having a list is limitative: why only those organizations (whichever they end up being) have that privilege? I'm really wondering if this restriction (the first option) is necessary: the TC is in charge of accepting or not the new modules, so it can refuse anything, including modules namespaces from those organizations. What is important IMO is to state that one cannot refuse a namespace on the ground that only TC-defined namespaces are allowed. I've tried to capture this in the second option. I made an alternative proposal that IMHO addresses Fredrik's, Yves' and hopefully also Rodolfo's concerns I made the list of allowed standards bodies exemplary rather than enumerative. Yet I clearly stated that private namespaces must be replaced by TC defined namespaces when promoting an private extension (member submission) to module. Regards, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org


  • 6.  RE: [xliff] Namespace in modules

    Posted 11-08-2012 11:42
    Hi David,   I like your proposal 3. I do not think we should limit ourselves to a specific list, there are too many standards bodies out there. I see the requirement for final standard from recognized standards body as a guideline helping anyone wanting to create a module determine if it is likely the TC would accept such a module at least from the procedural / formal requirements point. And also as a guideline for the TC when reviewing a proposed module. As Yves has already pointed out in the original mail, acceptance of modules will still come down to a TC vote. But having clear guidelines on the non-technical parts should help the creation and review process. Without some agreed guidelines we are likely doomed to have the same discussion the next time the issue is raised.   One additional constraint I think we should consider, or at least discuss, for the modules is the IPR. I do not think it would be good, or possibly even allowed by OASIS, for us to accept external namespaces where the IP rights is incompatible with the IPR of OASIS and the XLIFF charter into an official module. It would probably make sense if the proposer include information on this with the module.   On the specific ITS usage, I do not see a problem using parts of ITS 2.0 once final in a module.   Regards, Fredrik Estreen   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip Sent: den 7 november 2012 00:25 To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Namespace in modules   Hi Yves, all, one alternative proposal 3 and a few comments inline.. Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Tue, Nov 6, 2012 at 9:35 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi all, I had the action item to specify a proposal regarding the namespace in modules: === first, some background: Currently the part of the draft defining a module says this: "A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each official module defined for XLIFF 2.0 has its grammar defined in an independent XML Schema with a separate namespace." Based on that: -1 there is no restriction on what the namespace of the module is. -2 It doesn't say you can use several namespaces, like we do with matches or glossary for example (where we use the XML and the core namespaces), so technically we could biker about the existing modules. -3 it doesn't say any think about the version of the core and the modules -4 it doesn't say anything about where modules could be set (so by default that could be anywhere). The immediate concern I have is to make sure the ITS WG can map its metadata to XLIFF. As it stands now, we cannot. To be able to do it we would need either: -A) That the <mrk> element allows extended attributes -B) that we can for sure have a module allowing us to use ITS native markup in <mrk> The solution A) is actually rather logical: <mrk> is where tools annotate the content, there is a limited mechanism in place that allows user-defined metadata to a certain extent, but it a bit like <metadata> for the element: it's not enough in several of our use cases. The main problem with having extension at the segment level is about what to do with the data when re-segmenting. But in the case of <mrk> that problem does not occurs since it's an inline element. But for various reason I think having a module instead is fine, and even probably better as it formalizes things a bit more. I agree that module is better but the first step to that module should be anyway <mrk> and <note> extensibility. As any other new module that is not specified as module outright,  the modules will evolve from broadly adopted extensions. So I want to make sure solution B) is doable. That in Dec-2013 when ITS 2.0 becomes a recommendation we can add a new module to XLIFF that simply uses the ITS native attributes. The text we have currently is actually ok to achieve that, but as one could see this morning, that is not necessarily the opinion of everyone. So I want to make sure we have clear rules on how to add/remove modules in XLIFF. === A proposal: So here is a possible text proposal for the section 1.1.3 entry "XLIFF Module". Maybe it should have a separate section, but that is not important: A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can be placed in locations that are not extension points. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF, even if no other part of the specification has changed. I would remove ", even if no other part of the specification has changed" If nothing else the spec will need to specify place and order of the new module etc.  -- Either 1: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), from the World Wide Web Consortium (W3C), from the European Telecommunications Standards Institute (ETSI), from ISO, or from the Unicode Consortium. -- Or 2: A module MUST only use namespaces of final specifications. The owners of these namespaces MAY be OASIS or other organizations. Alternative proposal 3: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the Inetranational Standards Organization, or the Unicode Consortium. Namespaces of private custom extensions (member submissions) promoted to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces.   === and some comments on the proposal - Adding a modules will require publishing a new version of XLIFF. Which is time consuming. I don't like that at all, but I don't see how otherwise make sure can modules evolve orderly. My concern is how much time will the TC take to add a new module. This is also why I think both module and extensions have the same PRs for core-only tools: this allows time without preventing the extension-moving-to-modules to be impaired. Any extension (including W3C ITS) should be protected by SHOULD rather than MUST until it becomes module, as only the committee process can ensure that it does not have harmful impact, and unlike module it can compete for functionality with other extensions.  - I understand Fredrik's concern about not allowing "any" namespace as possibly used in extensions, but at the same time having a list is limitative: why only those organizations (whichever they end up being) have that privilege? I'm really wondering if this restriction (the first option) is necessary: the TC is in charge of accepting or not the new modules, so it can refuse anything, including modules namespaces from those organizations. What is important IMO is to state that one cannot refuse a namespace on the ground that only TC-defined namespaces are allowed. I've tried to capture this in the second option. I made an alternative proposal that IMHO addresses Fredrik's, Yves' and hopefully also Rodolfo's concerns   I made the list of allowed standards bodies exemplary rather than enumerative. Yet I clearly stated that private namespaces must be replaced by TC defined namespaces when promoting an private extension (member submission) to module. Regards, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org  


  • 7.  RE: [xliff] Namespace in modules

    Posted 11-08-2012 12:11
    Hi David, Fredrik, all, I think option 3 is fine. I would just possibly reword one part of it from: > Namespaces of private custom extensions (member submissions) promoted > to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces. To: Namespaces of private custom extensions MUST be replaced by namespaces from OASIS or another standardization body to be promoted to a module. The rational: - I simply no idea what "member submission" means here and it doesn't seem to add much to the text. - Owners of private namespaces may prefer to 'standardize' their proposed namespace elsewhere than OASIS for whatever reason (e.g. membership they have, politics, whatever, re-usability, etc.) Adding something about the IP right is also a good idea. I think Rodolfo voiced that concern at the last call. I'm not sure how to word that though. Maybe something like: Namespaces used in a module MUST have IP rights compatible with the IP rights of the XLIFF specification. This would give us the following: ======== A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can be placed in locations that are not extension points. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF. A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC) or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the International Standards Organization, or the Unicode Consortium. Namespaces of private custom extensions MUST be replaced by namespaces from OASIS or another standardization body. Namespaces used in a module MUST have IP rights compatible with the IP of the XLIFF specification. ======== But I think we still have the 3rd paragraph to resolve. The wordings here reflect just what I currently think is the only way to add/remove module to the specification. But if there is another way that avoid publishing new version that would be great. I'm just not seeing other way. Regards, -yves From: Estreen, Fredrik [ mailto:Fredrik.Estreen@lionbridge.com ] Sent: Thursday, November 08, 2012 4:42 AM To: Dr. David Filip; Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] Namespace in modules Hi David, I like your proposal 3. I do not think we should limit ourselves to a specific list, there are too many standards bodies out there. I see the requirement for final standard from recognized standards body as a guideline helping anyone wanting to create a module determine if it is likely the TC would accept such a module at least from the procedural / formal requirements point. And also as a guideline for the TC when reviewing a proposed module. As Yves has already pointed out in the original mail, acceptance of modules will still come down to a TC vote. But having clear guidelines on the non-technical parts should help the creation and review process. Without some agreed guidelines we are likely doomed to have the same discussion the next time the issue is raised. One additional constraint I think we should consider, or at least discuss, for the modules is the IPR. I do not think it would be good, or possibly even allowed by OASIS, for us to accept external namespaces where the IP rights is incompatible with the IPR of OASIS and the XLIFF charter into an official module. It would probably make sense if the proposer include information on this with the module. On the specific ITS usage, I do not see a problem using parts of ITS 2.0 once final in a module. Regards, Fredrik Estreen From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Dr. David Filip Sent: den 7 november 2012 00:25 To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Namespace in modules Hi Yves, all, one alternative proposal 3 and a few comments inline.. Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Tue, Nov 6, 2012 at 9:35 PM, Yves Savourel <ysavourel@enlaso.com> wrote: Hi all, I had the action item to specify a proposal regarding the namespace in modules: === first, some background: Currently the part of the draft defining a module says this: "A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each official module defined for XLIFF 2.0 has its grammar defined in an independent XML Schema with a separate namespace." Based on that: -1 there is no restriction on what the namespace of the module is. -2 It doesn't say you can use several namespaces, like we do with matches or glossary for example (where we use the XML and the core namespaces), so technically we could biker about the existing modules. -3 it doesn't say any think about the version of the core and the modules -4 it doesn't say anything about where modules could be set (so by default that could be anywhere). The immediate concern I have is to make sure the ITS WG can map its metadata to XLIFF. As it stands now, we cannot. To be able to do it we would need either: -A) That the <mrk> element allows extended attributes -B) that we can for sure have a module allowing us to use ITS native markup in <mrk> The solution A) is actually rather logical: <mrk> is where tools annotate the content, there is a limited mechanism in place that allows user-defined metadata to a certain extent, but it a bit like <metadata> for the element: it's not enough in several of our use cases. The main problem with having extension at the segment level is about what to do with the data when re-segmenting. But in the case of <mrk> that problem does not occurs since it's an inline element. But for various reason I think having a module instead is fine, and even probably better as it formalizes things a bit more. I agree that module is better but the first step to that module should be anyway <mrk> and <note> extensibility. As any other new module that is not specified as module outright, the modules will evolve from broadly adopted extensions. So I want to make sure solution B) is doable. That in Dec-2013 when ITS 2.0 becomes a recommendation we can add a new module to XLIFF that simply uses the ITS native attributes. The text we have currently is actually ok to achieve that, but as one could see this morning, that is not necessarily the opinion of everyone. So I want to make sure we have clear rules on how to add/remove modules in XLIFF. === A proposal: So here is a possible text proposal for the section 1.1.3 entry "XLIFF Module". Maybe it should have a separate section, but that is not important: A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can be placed in locations that are not extension points. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF, even if no other part of the specification has changed. I would remove ", even if no other part of the specification has changed" If nothing else the spec will need to specify place and order of the new module etc. -- Either 1: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), from the World Wide Web Consortium (W3C), from the European Telecommunications Standards Institute (ETSI), from ISO, or from the Unicode Consortium. -- Or 2: A module MUST only use namespaces of final specifications. The owners of these namespaces MAY be OASIS or other organizations. Alternative proposal 3: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the Inetranational Standards Organization, or the Unicode Consortium. Namespaces of private custom extensions (member submissions) promoted to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces. === and some comments on the proposal - Adding a modules will require publishing a new version of XLIFF. Which is time consuming. I don't like that at all, but I don't see how otherwise make sure can modules evolve orderly. My concern is how much time will the TC take to add a new module. This is also why I think both module and extensions have the same PRs for core-only tools: this allows time without preventing the extension-moving-to-modules to be impaired. Any extension (including W3C ITS) should be protected by SHOULD rather than MUST until it becomes module, as only the committee process can ensure that it does not have harmful impact, and unlike module it can compete for functionality with other extensions. - I understand Fredrik's concern about not allowing "any" namespace as possibly used in extensions, but at the same time having a list is limitative: why only those organizations (whichever they end up being) have that privilege? I'm really wondering if this restriction (the first option) is necessary: the TC is in charge of accepting or not the new modules, so it can refuse anything, including modules namespaces from those organizations. What is important IMO is to state that one cannot refuse a namespace on the ground that only TC-defined namespaces are allowed. I've tried to capture this in the second option. I made an alternative proposal that IMHO addresses Fredrik's, Yves' and hopefully also Rodolfo's concerns I made the list of allowed standards bodies exemplary rather than enumerative. Yet I clearly stated that private namespaces must be replaced by TC defined namespaces when promoting an private extension (member submission) to module. Regards, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org


  • 8.  Re: [xliff] Namespace in modules

    Posted 11-08-2012 19:21
    Yves, member submission is an established term (although it is used rather in W3C than OASIS, it was in parentheses and intended solely as parsing help for a standardization worker used to other lingos), many standards have been developed based on member submissions (e.g. DITA started as a member submission by IBM). Standards can be either developed from scratch in committee, be submitted by a member or by another standardization body. This distinction is important here. We are happy to accept namespaces from standardization bodies on par with XLIFF TC, but we are not happy to accept privately hosted namespaces, and we want to replace them with XLIFF TC defined namespaces. We cannot replace them with any other, because we do not have jurisdiction over any other. Let's assume that you wanted to turn your private okp: extensions into an XLIFF module, you can either make a member submission directly to OASIS XLIFF TC, or you may decide to formalize the okp extensions first through W3C ITS 2.0 Either is a valid approach, but only in the case of a direct member submission, the okp: namespace will be replaced by an XLIFF TC   defined namespace.  It is irrelevant if your extension make it into the XLIFF standard through an ITS namespace, but it is also no longer a case of a promotion of a private extension to a module. This case covered by accepting foreign namespaces guaranteed by established standardization bodies. So I really mean it if I say that private extension namespaces MUST be replaced by XLIFF TC namespaces and no other, because you cannot AT THE SAME TIME pursue a promotion of a private extension AND establish your namespace with a third party standardization body. I really believe that my original formulation says what needs to be said. I also think that in the currently proposed 1 sentnece paragraph the IPR constraint is not sufficiently clear and explicit. Below I am suggesting a wording based on my previous reply to Frdrik. Let me propose the complete wording: ´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´ A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used.  Modules can generally be placed in locations that are not extension points, with some restrictions, for example module elements are not allowed inside <source> or <target> elements. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF. A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC) or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the International Standards Organization, or the Unicode Consortium.  Namespaces of private custom extensions promoted  to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces. Private submitters MUST disclose any essential claims at the time of the submission and clear any declared essential claims for royalty free use according to the module specification. In case a module is proposed as based on another standardization body's specification or namespace, the submitters MUST declare its IPR mode including all essential claims, and whether these have been cleared for royalty free use according to the original specification and in the proposed module. XLIFF TC SHALL NOT accept any royalty encumbered submissions for modules. ´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´ Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Thu, Nov 8, 2012 at 12:10 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, Fredrik, all, I think option 3 is fine. I would just possibly reword one part of it from: > Namespaces of private custom extensions (member submissions) promoted > to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces. To: Namespaces of private custom extensions MUST be replaced by namespaces from OASIS or another standardization body to be promoted to a module. The rational: - I simply no idea what "member submission" means here and it doesn't seem to add much to the text. - Owners of private namespaces may prefer to 'standardize' their proposed namespace elsewhere than OASIS for whatever reason (e.g. membership they have, politics, whatever, re-usability, etc.) Adding something about the IP right is also a good idea. I think Rodolfo voiced that concern at the last call. I'm not sure how to word that though. Maybe something like: Namespaces used in a module MUST have IP rights compatible with the IP rights of the XLIFF specification. This would give us the following: ======== A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can be placed in locations that are not extension points. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF. A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC) or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the International Standards Organization, or the Unicode Consortium. Namespaces of private custom extensions MUST be replaced by namespaces from OASIS or another standardization body. Namespaces used in a module MUST have IP rights compatible with the IP of the XLIFF specification. ======== But I think we still have the 3rd paragraph to resolve. The wordings here reflect just what I currently think is the only way to add/remove module to the specification. But if there is another way that avoid publishing new version that would be great. I'm just not seeing other way. Regards, -yves From: Estreen, Fredrik [mailto: Fredrik.Estreen@lionbridge.com ] Sent: Thursday, November 08, 2012 4:42 AM To: Dr. David Filip; Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] Namespace in modules Hi David, I like your proposal 3. I do not think we should limit ourselves to a specific list, there are too many standards bodies out there. I see the requirement for final standard from recognized standards body as a guideline helping anyone wanting to create a module determine if it is likely the TC would accept such a module at least from the procedural / formal requirements point. And also as a guideline for the TC when reviewing a proposed module. As Yves has already pointed out in the original mail, acceptance of modules will still come down to a TC vote. But having clear guidelines on the non-technical parts should help the creation and review process. Without some agreed guidelines we are likely doomed to have the same discussion the next time the issue is raised. One additional constraint I think we should consider, or at least discuss, for the modules is the IPR. I do not think it would be good, or possibly even allowed by OASIS, for us to accept external namespaces where the IP rights is incompatible with the IPR of OASIS and the XLIFF charter into an official module. It would probably make sense if the proposer include information on this with the module. On the specific ITS usage, I do not see a problem using parts of ITS 2.0 once final in a module. Regards, Fredrik Estreen From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Dr. David Filip Sent: den 7 november 2012 00:25 To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Namespace in modules Hi Yves, all, one alternative proposal 3 and a few comments inline.. Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Tue, Nov 6, 2012 at 9:35 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi all, I had the action item to specify a proposal regarding the namespace in modules: === first, some background: Currently the part of the draft defining a module says this: "A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each official module defined for XLIFF 2.0 has its grammar defined in an independent XML Schema with a separate namespace." Based on that: -1 there is no restriction on what the namespace of the module is. -2 It doesn't say you can use several namespaces, like we do with matches or glossary for example (where we use the XML and the core namespaces), so technically we could biker about the existing modules. -3 it doesn't say any think about the version of the core and the modules -4 it doesn't say anything about where modules could be set (so by default that could be anywhere). The immediate concern I have is to make sure the ITS WG can map its metadata to XLIFF. As it stands now, we cannot. To be able to do it we would need either: -A) That the <mrk> element allows extended attributes -B) that we can for sure have a module allowing us to use ITS native markup in <mrk> The solution A) is actually rather logical: <mrk> is where tools annotate the content, there is a limited mechanism in place that allows user-defined metadata to a certain extent, but it a bit like <metadata> for the element: it's not enough in several of our use cases. The main problem with having extension at the segment level is about what to do with the data when re-segmenting. But in the case of <mrk> that problem does not occurs since it's an inline element. But for various reason I think having a module instead is fine, and even probably better as it formalizes things a bit more. I agree that module is better but the first step to that module should be anyway <mrk> and <note> extensibility. As any other new module that is not specified as module outright,  the modules will evolve from broadly adopted extensions. So I want to make sure solution B) is doable. That in Dec-2013 when ITS 2.0 becomes a recommendation we can add a new module to XLIFF that simply uses the ITS native attributes. The text we have currently is actually ok to achieve that, but as one could see this morning, that is not necessarily the opinion of everyone. So I want to make sure we have clear rules on how to add/remove modules in XLIFF. === A proposal: So here is a possible text proposal for the section 1.1.3 entry "XLIFF Module". Maybe it should have a separate section, but that is not important: A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can be placed in locations that are not extension points. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF, even if no other part of the specification has changed. I would remove ", even if no other part of the specification has changed" If nothing else the spec will need to specify place and order of the new module etc. -- Either 1: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), from the World Wide Web Consortium (W3C), from the European Telecommunications Standards Institute (ETSI), from ISO, or from the Unicode Consortium. -- Or 2: A module MUST only use namespaces of final specifications. The owners of these namespaces MAY be OASIS or other organizations. Alternative proposal 3: A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC), or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the Inetranational Standards Organization, or the Unicode Consortium. Namespaces of private custom extensions (member submissions) promoted to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces. === and some comments on the proposal - Adding a modules will require publishing a new version of XLIFF. Which is time consuming. I don't like that at all, but I don't see how otherwise make sure can modules evolve orderly. My concern is how much time will the TC take to add a new module. This is also why I think both module and extensions have the same PRs for core-only tools: this allows time without preventing the extension-moving-to-modules to be impaired. Any extension (including W3C ITS) should be protected by SHOULD rather than MUST until it becomes module, as only the committee process can ensure that it does not have harmful impact, and unlike module it can compete for functionality with other extensions. - I understand Fredrik's concern about not allowing "any" namespace as possibly used in extensions, but at the same time having a list is limitative: why only those organizations (whichever they end up being) have that privilege? I'm really wondering if this restriction (the first option) is necessary: the TC is in charge of accepting or not the new modules, so it can refuse anything, including modules namespaces from those organizations. What is important IMO is to state that one cannot refuse a namespace on the ground that only TC-defined namespaces are allowed. I've tried to capture this in the second option. I made an alternative proposal that IMHO addresses Fredrik's, Yves' and hopefully also Rodolfo's concerns I made the list of allowed standards bodies exemplary rather than enumerative. Yet I clearly stated that private namespaces must be replaced by TC defined namespaces when promoting an private extension (member submission) to module. Regards, -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


  • 9.  RE: [xliff] Namespace in modules

    Posted 11-09-2012 18:09
    I think we agree David: Private namespaces cannot be used in a module, they have to be moved under a standardization body (including XLIFF TC) before/when the TC adopt the module. Your sentence: "Namespaces of private custom extensions promoted to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces." Is too limitative. It seems to indicate that the *only* way to migrate a private namespace to a "standard" that is acceptable in a module is to go through the TC, it doesn't monition the indirect way of using a different standardization body. I think the solution is simply to state that private namespaces cannot be part of a module and let the interested parties figure out how to move to a namespace that is acceptable. The text for the specification should simply state what a module is. Most of the "how" to create a module should probably reside in a note or some other document that describes the steps to migrate an extension to a module. The same goes for the IPR text. I think we should just state that the IPR/License of a proposed module must be compatible with the OASIS IPR/License requirements and define what it means somewhere else. So I would propose: ========== A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can generally be placed in locations that are not extension points, with some restrictions, for example module elements are not allowed inside <source> or <target> elements. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF. A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC) or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the International Standards Organization, or the Unicode Consortium. Private custom namespaces MUST NOT be used in modules. The IPR and license of a proposed module MUST be compatible with the OASIS IPR and license requirements and policies. ========== But we still have not resolved the general issue about versions and how adding/removing a module affect the specification (third paragraph of the proposal). Regards, -yves


  • 10.  Re: [xliff] Namespace in modules

    Posted 11-09-2012 19:33
    Yves, you are right that details such as the essential claims declaration would be best covered with a committee note. I am fine with the general statement re private namespaces. Regarding the 3rd paragraph, I am fine with the wording. It seems clear that modules require a full spec increment, as a note would not be enough to modify the standard. Notes might be eventually used to clarify and detail stuff mentioned in the spec. I would suggest to start work on a modules and profiles note early next year. I would still suggest one small change. The IPR mode and license of a proposed module MUST be compatible with the OASIS XLIFF TC IPR mode (RF on RAND terms)  and conform to relevant OASIS license requirements and policies. The reason for this rephrasing is that OASIS allows its committees to have several different and eventually incompatible IPR modes, so even the general text in the specification needs to be more specific. By requesting compatibility with *any* OASIS IPR mode, we would actually violate our charter that specifically states RF on RAND. Cheers and weekend dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Fri, Nov 9, 2012 at 6:08 PM, Yves Savourel < ysavourel@enlaso.com > wrote: I think we agree David: Private namespaces cannot be used in a module, they have to be moved under a standardization body (including XLIFF TC) before/when the TC adopt the module. Your sentence: "Namespaces of private custom extensions promoted to official XLIFF modules must be replaced by OASIS XLIFF TC namespaces." Is too limitative. It seems to indicate that the *only* way to migrate a private namespace to a "standard" that is acceptable in a module is to go through the TC, it doesn't monition the indirect way of using a different standardization body. I think the solution is simply to state that private namespaces cannot be part of a module and let the interested parties figure out how to move to a namespace that is acceptable. The text for the specification should simply state what a module is. Most of the "how" to create a module should probably reside in a note or some other document that describes the steps to migrate an extension to a module. The same goes for the IPR text. I think we should just state that the IPR/License of a proposed module must be compatible with the OASIS IPR/License requirements and define what it means somewhere else. So I would propose: ========== A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can generally be placed in locations that are not extension points, with some restrictions, for example module elements are not allowed inside <source> or <target> elements. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF. A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC) or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the International Standards Organization, or the Unicode Consortium. Private custom namespaces MUST NOT be used in modules. The IPR and license of a proposed module MUST be compatible with the OASIS IPR and license requirements and policies. ========== But we still have not resolved the general issue about versions and how adding/removing a module affect the specification (third paragraph of the proposal). Regards, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org


  • 11.  RE: [xliff] Namespace in modules

    Posted 11-09-2012 19:49
    Hi David, No problem with your text on IPR. So the latest updated text would be: ========== A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can generally be placed in locations that are not extension points, with some restrictions, for example module elements are not allowed inside <source> or <target> elements. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF. A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC) or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the International Standards Organization, or the Unicode Consortium. Private custom namespaces MUST NOT be used in modules. The IPR mode and license of a proposed module MUST be compatible with the OASIS XLIFF TC IPR mode (RF on RAND terms) and conform to relevant OASIS license requirements and policies. ========== Like you I currently don't see how we could update the XLIFF schema to add/remove modules without changing the version. Using a note as Rodolfo seem not possible. But incrementing the version and republishing seems to be quite a complicated process too. I wonder if anyone else has ideas about that. -yves


  • 12.  RE: [xliff] Namespace in modules

    Posted 11-09-2012 20:39
    Hi, The third paragraph doesn't belong to the specification document. It describes a TC policy, best suited for our working charter, not the specification. Fourth and last paragraphs should go to the main charter. They don't prescribe how to use the XLIFF format but are relevant for the charter to let outsiders know how to collaborate with the TC. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com Maxprograms http://www.maxprograms.com >
    Original Message


  • 13.  Re: [xliff] Namespace in modules

    Posted 11-09-2012 22:17
    Rodolfo, while I agree that some of this stuff should be reflected in the TC Charter (and in a working program charter if we had one), I believe that the current proposed wording (by Yves, including my IPR clarification) (re-pasted below) is the minimum on future modules that should be included in the spec itself. People should find relevant information in one place and not be forced to search multiple documents to figure vital info about modules. Also it is useful as a reminder for any future maintainers of the spec. This module conception is key for 2.x versions backwards compatibility, as it will become very difficult to change (by design) as part of an OASIS standard. If this stuff was detailed in a note, which is not normative, or a working charter only (which is even not an official document), it is dead easy to change. If we on the other hand put too much into the TC Charter, we might inadvertently trigger rechartering.. I propose an electronic ballot on including the current final text developed in this conversation as the future modules provision in the 2.0 spec. Looking for a second. Ballot should go: Include the following (re-pasted below) text in spec (YES NO) Comment prohibited  Cheers dF ========== A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can generally be placed in locations that are not extension points, with some restrictions, for example module elements are not allowed inside <source> or <target> elements. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF. A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC) or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the International Standards Organization, or the Unicode Consortium. Private custom namespaces MUST NOT be used in modules. The IPR mode and license of a proposed module MUST be compatible with the OASIS XLIFF TC IPR mode (RF on RAND terms) and conform to relevant OASIS license requirements and policies. ========== Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Fri, Nov 9, 2012 at 8:38 PM, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi, The third paragraph doesn't belong to the specification document. It describes a TC policy, best suited for our working charter, not the specification. Fourth and last paragraphs should go to the main charter. They don't prescribe how to use the XLIFF format but are relevant for the charter to let outsiders know how to collaborate with the TC. Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com >
    Original Message


  • 14.  RE: [xliff] Namespace in modules

    Posted 11-09-2012 23:21
    Hi David, all I second this proposed ballot. Regards, Fredrik Estreen ________________________________________ From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Dr. David Filip [David.Filip@ul.ie] Sent: Friday, November 09, 2012 11:16 PM To: Rodolfo M. Raya Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Namespace in modules Rodolfo, while I agree that some of this stuff should be reflected in the TC Charter (and in a working program charter if we had one), I believe that the current proposed wording (by Yves, including my IPR clarification) (re-pasted below) is the minimum on future modules that should be included in the spec itself. People should find relevant information in one place and not be forced to search multiple documents to figure vital info about modules. Also it is useful as a reminder for any future maintainers of the spec. This module conception is key for 2.x versions backwards compatibility, as it will become very difficult to change (by design) as part of an OASIS standard. If this stuff was detailed in a note, which is not normative, or a working charter only (which is even not an official document), it is dead easy to change. If we on the other hand put too much into the TC Charter, we might inadvertently trigger rechartering.. I propose an electronic ballot on including the current final text developed in this conversation as the future modules provision in the 2.0 spec. Looking for a second. Ballot should go: Include the following (re-pasted below) text in spec (YES NO) Comment prohibited Cheers dF ========== A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated into the document as result of that process. Each module is defined in a section of the XLIFF specification. The schemas of the XLIFF core or modules indicate where the elements and attributes of each module can be used. Modules can generally be placed in locations that are not extension points, with some restrictions, for example module elements are not allowed inside <source> or <target> elements. Each version of XLIFF has a fix set of modules. Adding or removing one or more modules from the latest version of XLIFF requires to increment the version of XLIFF. A module MUST use namespaces of only final specifications from OASIS (including the ones produced by the XLIFF TC) or from other established standardization bodies such as the World Wide Web Consortium (W3C), the European Telecommunications Standards Institute (ETSI), the International Standards Organization, or the Unicode Consortium. Private custom namespaces MUST NOT be used in modules. The IPR mode and license of a proposed module MUST be compatible with the OASIS XLIFF TC IPR mode (RF on RAND terms) and conform to relevant OASIS license requirements and policies. ========== Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie< mailto:david.filip@ul.ie > On Fri, Nov 9, 2012 at 8:38 PM, Rodolfo M. Raya <rmraya@maxprograms.com< mailto:rmraya@maxprograms.com >> wrote: Hi, The third paragraph doesn't belong to the specification document. It describes a TC policy, best suited for our working charter, not the specification. Fourth and last paragraphs should go to the main charter. They don't prescribe how to use the XLIFF format but are relevant for the charter to let outsiders know how to collaborate with the TC. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com< mailto:rmraya@maxprograms.com > Maxprograms http://www.maxprograms.com >
    Original Message


Related Content