OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi David, Ryan, Soroush, all, Maybe a good way to clarify whether or not any modules can be in an extension point is to look at an example: Currently the <res:resourceData> element is not listed in the <group> element. Can a user still add one anyway? The schema uses ##other and allows it, and AFAIK there is no *explicit text* in the specification that says it cannot be placed in <group>. == A) If the answer is "yes <res:resourceData> can be added in <group>" then: -A.1) Why did we bother to list some modules in <group> (and other elements)? -A.2) Why did we seem to go to great lengths to somehow indicate which modules could go in which extension point? (As shown for example in https://lists.oasis-open.org/archives/xliff/201312/msg00077.html ) == B) If the answer is "no <res:resourceData> cannot be added in <group>" then: - B.1) That probably means <mda:metadata> should not be used in <gls:glossEntry> either. Because the pattern is the same: ##other in the schema, and modules using modules list them explicitly (like <mda:metadata> in <mtc:match>) I would tend to think the answer to the question is "no" (A). I think that because if the answer is "yes", I can't find a rational explanation for A.1 and A2. Also, in the Matches module: the <mda:metadata> element is declared outside the extension point. If we were to put a <mda:metadata> in glossary it could only be at the extension point. And that would be really strange to have such difference. So I think that by listing the modules in the specification we did meant to list those that were allowed. Note also that there was a discussion about having a <mda:metadata> in the glossary in 2012: https://lists.oasis-open.org/archives/xliff/201211/msg00111.html (It looks eerily similar to the one of this week-end: https://lists.oasis-open.org/archives/xliff/201505/msg00016.html ). There was apparently no follow-up conclusion in 2012, which led by default to no <mda:metadata> in glossary. Regardless of the merit of <mda:metadata> in modules, I'm glad Ryan brought up the issue, because either ways, the specification really needs to be clarify on the topic of modules in extension points. Hopefully that can be done during the F2F meeting. Cheers, -yves

Hi Yves, David, Soroush, all, I think Yves logic here makes sense with the way the spec has been written (even if the intent was something different). So, until we can discuss further and make possible clarifications in 2.1, the safest interpretation for implementing 2.0 is the literal one: Extensions can appear at any extension point, but Modules can only appear where they are explicitly called out, which makes my use case not optimal, but still manageable (I'll have example implementations in Berlin). Thanks all for the discussion, Ryan From: Yves Savourel Sent: ?5/?24/?2015 6:05 AM To: XLIFF Main List Subject: [xliff] Extensibility in Core and Modules Hi David, Ryan, Soroush, all, Maybe a good way to clarify whether or not any modules can be in an extension point is to look at an example: Currently the <res:resourceData> element is not listed in the <group> element. Can a user still add one anyway? The schema uses ##other and allows it, and AFAIK there is no *explicit text* in the specification that says it cannot be placed in <group>. == A) If the answer is "yes <res:resourceData> can be added in <group>" then: -A.1) Why did we bother to list some modules in <group> (and other elements)? -A.2) Why did we seem to go to great lengths to somehow indicate which modules could go in which extension point? (As shown for example in https://lists.oasis-open.org/archives/xliff/201312/msg00077.html ) == B) If the answer is "no <res:resourceData> cannot be added in <group>" then: - B.1) That probably means <mda:metadata> should not be used in <gls:glossEntry> either. Because the pattern is the same: ##other in the schema, and modules using modules list them explicitly (like <mda:metadata> in <mtc:match>) I would tend to think the answer to the question is "no" (A). I think that because if the answer is "yes", I can't find a rational explanation for A.1 and A2. Also, in the Matches module: the <mda:metadata> element is declared outside the extension point. If we were to put a <mda:metadata> in glossary it could only be at the extension point. And that would be really strange to have such difference. So I think that by listing the modules in the specification we did meant to list those that were allowed. Note also that there was a discussion about having a <mda:metadata> in the glossary in 2012: https://lists.oasis-open.org/archives/xliff/201211/msg00111.html (It looks eerily similar to the one of this week-end: https://lists.oasis-open.org/archives/xliff/201505/msg00016.html ). There was apparently no follow-up conclusion in 2012, which led by default to no <mda:metadata> in glossary. Regardless of the merit of <mda:metadata> in modules, I'm glad Ryan brought up the issue, because either ways, the specification really needs to be clarify on the topic of modules in extension points. Hopefully that can be done during the F2F meeting. Cheers, -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Ryan, Yves, all I strongly disagree with this interpretation. Reuse of module namespaces as extensions is NOT prohibited anywhere in the spec. It just doesn't make sense to prohibit that. We intended modules to be used at certain places but we did never ever prohibit *reusing their namespaces as extensions*. If people find mda useful at a general extension point that's great, especially if they don't want to specify and maintain their own namespace.. We might go and improve the status of mda at that extension point in the next version if more people find it useful.  Module namespaces reused at general extension points are simply not modules, even though their namespaces are XLIFF defined. Being XLIFF defined is a necessary but not a sufficient condition for something being a module. This is just a 2 and half thousand years old logical distinction.. There is no need to call INTENT because the logic of the spec is NOT equivocal and we MUST NOT invent additional constraints that are NOT specified in the standard. @Yves, we went to great lengths to allow modules at specific extension points to ensure their status as MODULES (as opposed to extensions) at those extension points because their status was equivocal under XSD uniqueness rules. This is a very good reason per se and no need to go looking for some mysterious additional intent. Cheers dF Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer  LRC CNGL CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto:  david.filip@ul.ie On Sun, May 24, 2015 at 8:20 PM, Ryan King < ryanki@microsoft.com > wrote: Hi Yves, David, Soroush, all, I think Yves logic here makes sense with the way the spec has been written (even if the intent was something different). So, until we can discuss further and make possible clarifications in 2.1, the safest interpretation for implementing 2.0 is the literal one: Extensions can appear at any extension point, but Modules can only appear where they are explicitly called out, which makes my use case not optimal, but still manageable (I'll have example implementations in Berlin). Thanks all for the discussion, Ryan From: Yves Savourel Sent: ?5/?24/?2015 6:05 AM To: XLIFF Main List Subject: [xliff] Extensibility in Core and Modules Hi David, Ryan, Soroush, all, Maybe a good way to clarify whether or not any modules can be in an extension point is to look at an example: Currently the <res:resourceData> element is not listed in the <group> element. Can a user still add one anyway? The schema uses ##other and allows it, and AFAIK there is no *explicit text* in the specification that says it cannot be placed in <group>. == A) If the answer is "yes <res:resourceData> can be added in <group>" then: -A.1) Why did we bother to list some modules in <group> (and other elements)? -A.2) Why did we seem to go to great lengths to somehow indicate which modules could go in which extension point? (As shown for example in https://lists.oasis-open.org/archives/xliff/201312/msg00077.html ) == B) If the answer is "no <res:resourceData> cannot be added in <group>" then: - B.1) That probably means <mda:metadata> should not be used in <gls:glossEntry> either. Because the pattern is the same: ##other in the schema, and modules using modules list them explicitly (like <mda:metadata> in <mtc:match>) I would tend to think the answer to the question is "no" (A). I think that because if the answer is "yes", I can't find a rational explanation for A.1 and A2. Also, in the Matches module: the <mda:metadata> element is declared outside the extension point. If we were to put a <mda:metadata> in glossary it could only be at the extension point. And that would be really strange to have such difference. So I think that by listing the modules in the specification we did meant to list those that were allowed. Note also that there was a discussion about having a <mda:metadata> in the glossary in 2012: https://lists.oasis-open.org/archives/xliff/201211/msg00111.html (It looks eerily similar to the one of this week-end: https://lists.oasis-open.org/archives/xliff/201505/msg00016.html ). There was apparently no follow-up conclusion in 2012, which led by default to no <mda:metadata> in glossary. Regardless of the merit of <mda:metadata> in modules, I'm glad Ryan brought up the issue, because either ways, the specification really needs to be clarify on the topic of modules in extension points. Hopefully that can be done during the F2F meeting. Cheers, -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Dear David, all, > Reuse of module namespaces as extensions is NOT prohibited > anywhere in the spec. > It just doesn't make sense to prohibit that. > We intended modules to be used at certain places but we > did never ever prohibit *reusing their namespaces as extensions*. The extension mechanism is defined as follow: [[ XLIFF 2.0 offers two mechanisms for storing custom data in an XLIFF document: - Using the Metadata module for storing custom data in elements defined by the official XLIFF specification. - Using the standard XML namespace mechanism for storing data in elements or attributes defined in a custom XML Schema. Both mechanisms can be used simultaneously. ]] This is clear to me: Extensions can be carried by either Metadata (as a module, where defined) or by a custom namespace. The namespaces of modules are not 'custom namespaces' (hopefully we agree on that), hence they cannot be extensions. There no provision in the specification and no discussion the email archives (as far as I can tell) that show the TC ever intended to allow the modules to be used like extensions. > Module namespaces reused at general extension points are simply > not modules, even though their namespaces are XLIFF defined. Modules are modules. If they are not listed in the specification they cannot be used at all. A module is defined by the TC and has specific PRs, locations, relationship with the core, etc. An agent cannot re-purpose a whole module to mean something else. For example the <res:resourceData> element means something in <file> (where it is listed by the specification), it cannot mean something else in <group> (where it is not listed, and according your interpretation, could be used as an 'extension'). It would be utterly confusing for the users and a mess for the implementer. > Being XLIFF defined is a necessary but not a sufficient condition for > something being a module. What are the other conditions to be a module? (And where do you see them defined in the specification?) > If people find mda useful at a general extension point that's great, > especially if they don't want to specify and maintain their > own namespace. Metadata is certainly meant to hold custom data, no question there. But because it is a module it must follow the rules we have set for the modules: Not listed means not allowed there. Ideally the specification would allow <mda:metadata> in every single extension point. I have nothing against that. It would make sense. But for some reasons, we do not have that situation for the modules. Somehow the TC ended up listing Metadata only in the Matches module. Let's face it: that was a mistake. But let's not try to correct that mistake by suddenly allowing modules to be treated like extensions. That, by the way, would still not really solve Ryan's issue, because Metadata would still not be seen as Metadata by the tools supporting Metadata. So there is no real point trying to do that anyway. > There is no need to call INTENT because the logic of the spec is NOT > equivocal and we MUST NOT invent additional constraints that are NOT > specified in the standard. The specification a bit equivocal here because (after all that is why we have that discussion). It's very easy to forget that the schema doesn't enforce all requirements so anything that complements the schema should be very clear. The fact that I started by answering "Sure you can use metadata as an extension" to Ryan until he noticed that the validation didn't allow it, and the fact that you still say it is OK, shows me that the text of the specification need to be clearer (regardless which interpretation is correct). > @Yves, we went to great lengths to allow modules at specific > extension points to ensure their status as MODULES (as opposed to extensions) > at those extension points because their status was equivocal under > XSD uniqueness rules. I may have missed something, but again, where in the specification (or in the email archives) is there any statement or discussion that a module can be an extension? The definition of the extension mechanism shows that such interpretation is incorrect. We went to great lengths to express which module was allowed at which location, nothing more. Cheers, -yves

@Yves, allowing mda on all extension points works for me We can discuss explicitly prohibiting modules where they are not listed in the spec. Will you be able to attend at least a part of the f2f online to resolve this? I don't think it makes sense to continue the discussion of the intent, while we could continue arguing, it wouldn't really help solve the issue. For Ryan's case, Ryan you could use the TBX namespace to extend the gls, the advantage would be that you would have 1-1 TBX mapping as gls and core (term annotation) map 1-1 to the compulsory subset of TBX Basic. Although I think that you are OK to add mda on gls, this is not the TC consensus and mda can be explicitly allowed for 2.1 the soonest. Also TBX has the terminology business logic and is broadly supported by TB systems.. Cheers dF   Cheers dF Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer  LRC CNGL CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto:  david.filip@ul.ie On Tue, May 26, 2015 at 3:31 AM, Yves Savourel < ysavourel@enlaso.com > wrote: Dear David, all, > Reuse of module namespaces as extensions is NOT prohibited > anywhere in the spec. > It just doesn't make sense to prohibit that. > We intended modules to be used at certain places but we > did never ever prohibit *reusing their namespaces as extensions*. The extension mechanism is defined as follow: [[ XLIFF 2.0 offers two mechanisms for storing custom data in an XLIFF document: - Using the Metadata module for storing custom data in elements defined by the official XLIFF specification. - Using the standard XML namespace mechanism for storing data in elements or attributes defined in a custom XML Schema. Both mechanisms can be used simultaneously. ]] This is clear to me: Extensions can be carried by either Metadata (as a module, where defined) or by a custom namespace. The namespaces of modules are not 'custom namespaces' (hopefully we agree on that), hence they cannot be extensions. There no provision in the specification and no discussion the email archives (as far as I can tell) that show the TC ever intended to allow the modules to be used like extensions. > Module namespaces reused at general extension points are simply > not modules, even though their namespaces are XLIFF defined. Modules are modules. If they are not listed in the specification they cannot be used at all. A module is defined by the TC and has specific PRs, locations, relationship with the core, etc. An agent cannot re-purpose a whole module to mean something else. For example the <res:resourceData> element means something in <file> (where it is listed by the specification), it cannot mean something else in <group> (where it is not listed, and according your interpretation, could be used as an 'extension'). It would be utterly confusing for the users and a mess for the implementer. > Being XLIFF defined is a necessary but not a sufficient condition for > something being a module. What are the other conditions to be a module? (And where do you see them defined in the specification?) > If people find mda useful at a general extension point that's great, > especially if they don't want to specify and maintain their > own namespace. Metadata is certainly meant to hold custom data, no question there. But because it is a module it must follow the rules we have set for the modules: Not listed means not allowed there. Ideally the specification would allow <mda:metadata> in every single extension point. I have nothing against that. It would make sense. But for some reasons, we do not have that situation for the modules. Somehow the TC ended up listing Metadata only in the Matches module. Let's face it: that was a mistake. But let's not try to correct that mistake by suddenly allowing modules to be treated like extensions. That, by the way, would still not really solve Ryan's issue, because Metadata would still not be seen as Metadata by the tools supporting Metadata. So there is no real point trying to do that anyway. > There is no need to call INTENT because the logic of the spec is NOT > equivocal and we MUST NOT invent additional constraints that are NOT > specified in the standard. The specification a bit equivocal here because (after all that is why we have that discussion). It's very easy to forget that the schema doesn't enforce all requirements so anything that complements the schema should be very clear. The fact that I started by answering "Sure you can use metadata as an extension" to Ryan until he noticed that the validation didn't allow it, and the fact that you still say it is OK, shows me that the text of the specification need to be clearer (regardless which interpretation is correct). > @Yves, we went to great lengths to allow modules at specific > extension points to ensure their status as MODULES (as opposed to extensions) > at those extension points because their status was equivocal under > XSD uniqueness rules. I may have missed something, but again, where in the specification (or in the email archives) is there any statement or discussion that a module can be an extension? The definition of the extension mechanism shows that such interpretation is incorrect. We went to great lengths to express which module was allowed at which location, nothing more. Cheers, -yves --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi David, > We can discuss explicitly prohibiting modules where they > are not listed in the spec. > Will you be able to attend at least a part of the f2f online to > resolve this? No, sorry: I'll be on planes Monday and arrive after 5:30pm in Berlin. Cheers, -yves

Thanks David, I will have some examples of how we would need to implement this if mda were not allowed in gls, and how we would implement if it were. I haven’t
had time to look at the TBX mapping yet to see if it meets our needs, but could do that once I have a better understanding of the mapping.
 
I think it is important to discuss two things next week: 1) Allowing mda on all extension points, 2) Clarifying why some modules are explicit and others aren’t,
e.g. to borrow Yves’ example, why isn’t res allowed in <group>?  Would it be possible to have this discussion on Tues or Wed when Yves is present?
 
Ryan
 
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Dr. David Filip
Sent: Thursday, May 28, 2015 4:07 AM
To: Yves Savourel
Cc: XLIFF Main List
Subject: Re: [xliff] Extensibility in Core and Modules
 

@Yves, allowing mda on all extension points works for me

 


We can discuss explicitly prohibiting modules where they are not listed in the spec.


Will you be able to attend at least a part of the f2f online to resolve this?


I don't think it makes sense to continue the discussion of the intent, while we could continue arguing, it wouldn't really help solve the issue.


 


For Ryan's case, Ryan you could use the TBX namespace to extend the gls, the advantage would be that you would have 1-1 TBX mapping as gls and core (term annotation) map 1-1 to the compulsory subset of TBX Basic.


Although I think that you are OK to add mda on gls, this is not the TC consensus and mda can be explicitly allowed for 2.1 the soonest. Also TBX has the terminology business logic and is broadly supported by TB systems..


 


Cheers


dF


 


 


 


Cheers


dF


 










Dr. David Filip







=======================

OASIS XLIFF TC Secretary, Editor, and Liaison Officer 


LRC CNGL CSIS


University of Limerick, Ireland


telephone: +353-6120-2781


cellphone: +353-86-0222-158


facsimile: +353-6120-2734


http://www.cngl.ie/profile/?i=452


mailto:  david.filip@ul.ie









 

On Tue, May 26, 2015 at 3:31 AM, Yves Savourel < ysavourel@enlaso.com > wrote:

Dear David, all,


> Reuse of module namespaces as extensions is NOT prohibited
> anywhere in the spec.
> It just doesn't make sense to prohibit that.
> We intended modules to be used at certain places but we
> did never ever prohibit *reusing their namespaces as extensions*.

The extension mechanism is defined as follow:

[[
XLIFF 2.0 offers two mechanisms for storing custom data in an XLIFF document:
- Using the Metadata module for storing custom data in elements defined by the official XLIFF specification.
- Using the standard XML namespace mechanism for storing data in elements or attributes defined in a custom XML Schema.
Both mechanisms can be used simultaneously.
]]

This is clear to me: Extensions can be carried by either Metadata (as a module, where defined) or by a custom namespace.
The namespaces of modules are not 'custom namespaces' (hopefully we agree on that), hence they cannot be extensions.

There no provision in the specification and no discussion the email archives (as far as I can tell) that show the TC ever intended to allow the modules to be used like extensions.



> Module namespaces reused at general extension points are simply
> not modules, even though their namespaces are XLIFF defined.

Modules are modules. If they are not listed in the specification they cannot be used at all.

A module is defined by the TC and has specific PRs, locations, relationship with the core, etc. An agent cannot re-purpose a whole module to mean something else. For example the <res:resourceData> element means something in <file> (where it is listed by the
specification), it cannot mean something else in <group> (where it is not listed, and according your interpretation, could be used as an 'extension'). It would be utterly confusing for the users and a mess for the implementer.



> Being XLIFF defined is a necessary but not a sufficient condition for
> something being a module.

What are the other conditions to be a module?
(And where do you see them defined in the specification?)



> If people find mda useful at a general extension point that's great,
> especially if they don't want to specify and maintain their
> own namespace.

Metadata is certainly meant to hold custom data, no question there.
But because it is a module it must follow the rules we have set for the modules: Not listed means not allowed there.

Ideally the specification would allow <mda:metadata> in every single extension point. I have nothing against that. It would make sense. But for some reasons, we do not have that situation for the modules. Somehow the TC ended up listing Metadata only in the
Matches module. Let's face it: that was a mistake.

But let's not try to correct that mistake by suddenly allowing modules to be treated like extensions.
That, by the way, would still not really solve Ryan's issue, because Metadata would still not be seen as Metadata by the tools supporting Metadata. So there is no real point trying to do that anyway.



> There is no need to call INTENT because the logic of the spec is NOT
> equivocal and we MUST NOT invent additional constraints that are NOT
> specified in the standard.

The specification a bit equivocal here because (after all that is why we have that discussion).
It's very easy to forget that the schema doesn't enforce all requirements so anything that complements the schema should be very clear. The fact that I started by answering "Sure you can use metadata as an extension" to Ryan until he noticed that the validation
didn't allow it, and the fact that you still say it is OK, shows me that the text of the specification need to be clearer (regardless which interpretation is correct).


> @Yves, we went to great lengths to allow modules at specific
> extension points to ensure their status as MODULES (as opposed to extensions)
> at those extension points because their status was equivocal under
> XSD uniqueness rules.

I may have missed something, but again, where in the specification (or in the email archives) is there any statement or discussion that a module can be an extension? The definition of the extension mechanism shows that such interpretation is incorrect.
We went to great lengths to express which module was allowed at which location, nothing more.




Cheers,
-yves



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php