OASIS XML Localisation Interchange File Format (XLIFF) TC

Yves,   I looked in the archive for a continuation of this thread, which I was certain we’d begun. But I could not find anything. Hmmm. Now I’m having imaginary conversations about xml:space? Yikes!   I agree with your first point.  I think we should add a note in the xml:space section that say because the xml:space attribute is inherited by its descendants, <source> and <target> without xml:space attributes would still have their xml:space value set by an ancestor with xml:space.   When you say “I'm wondering if it's not worth having some note about this in the xml:space section,” are you referring to 4.3.2.2 xml:space?   If so, I propose we change it to:   - - - - - - - - - - - - - - - - - - - - Value description: default or preserve. The value default signals that an application's default white-space processing modes are acceptable for this element; the value preserve indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space attribute. For more information see the section on xml:space in the [XML] specification.   Default value: default   [add the following note] Note Because the xml:space attribute is not prohibited on elements that allow non-XLIFF namespace attributes, <source> or <target> elements that do not have an xml:space attribute could  inherit an xml:space value. If an ancestor element has an xml:space attribute, the <source> or <target> would inherit that value. - - - - - - - - - - - - - - - - - - - -   As for your second point:   “The specification also says for xml:space: ‘Default value: default ‘ Which is, from an XML viewpoint, incorrect. If it's not specified the value should be the same as the value for the parent element.”   I think you mean that elements who do not set their own xml:space, who descend from  elements which do have xml:space set to something, have the same value as that ancestor.   But I think if xml:space was not set on any ancestor, the Default value is still “default” for these <source> and <target> elements.   Therefore, I think the proposed solution above satisfies this point as well.   Thanks,   Bryan        From: "Yves Savourel" yves@opentag.com To: xliff-comment@lists.oasis-open.org Date: Wed, 2 Oct 2013 20:21:53 -0600 Subject: csprd02 comment - xml:lang and xml:space   Hi all,   The attributes xml:lang and xml:space can be used on <source> and <target>. But because they are in a non-XLIFF namespace, they presumably can also be used on elements that accept extended attributes.   Because, per the XML specification, those two attributes work with inheritance, one can set, for example, the xml:space value of a <source> or a <target> without declaring the attribute on that element:   <unit id='1' xml:space='preserve'> <segment>   <source>pre-formatted text</source> <!-- implicit xml:space='preserve' --> </segment> </unit>   There is no mention of this anywhere in the specification. I'm wondering if it's not worth having some note about this in the xml:space section.   The specification also says for xml:space:   Default value: default   Which is, from an XML viewpoint, incorrect. If it's not specified the value should be the same as the value for the parent element.   Regards, -yves

Hi Bryan, > When you say ?I'm wondering if it's not worth having some note about this > in the xml:space section,? are you referring to 4.3.2.2 xml:space? Yes. > [add the following note] > Note > Because the xml:space attribute is not prohibited on elements that allow > non-XLIFF namespace attributes, <source> or <target> elements that do > not have an xml:space attribute could inherit an xml:space value. > If an ancestor element has an xml:space attribute, the <source> or > <target> would inherit that value. Sounds fine to me. > As for your second point: > ... > I think you mean that elements who do not set their own xml:space, > who descend from  elements which do have xml:space set to something, > have the same value as that ancestor. Yes. > But I think if xml:space was not set on any ancestor, the Default value > is still ?default? for these <source> and <target> elements. > Therefore, I think the proposed solution above satisfies this point as well. Wouldn't be me more consistent to do like David did for srcDir and trgDir and indicates that the default value depends on the parent/ancestor? Cheers, -yves

Hi Yves, > Wouldn't be me more consistent to do like > David did for srcDir and trgDir and indicates > that the default value depends on the > parent/ancestor? The point I struggled to make was that we still need to account for the more common scenario, that in which no xml:space attribute occurs on the parent/ancestor - and no xml:space attribute occurs on the <source> and <target> <xliff> <file> <unit id="1"> <segment> <source>Yippy!</source> </segment> </unit> </file> </xliff> I don't recall the TC discussion about xml:space. But I think our whole reason for including the section in the spec is that in the absence of an explicit xml:space="preserve" on <source> or <target> is that we want the value to be "default." If we say "the default value depends on the parent/ancestor" we are not making our point. Maybe it's not so important? Thanks, Bryan ________________________________________ From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Yves Savourel [ysavourel@enlaso.com] Sent: Saturday, January 04, 2014 7:00 AM To: xliff@lists.oasis-open.org Subject: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Hi Bryan, > When you say “I'm wondering if it's not worth having some note about this > in the xml:space section,” are you referring to 4.3.2.2 xml:space? Yes. > [add the following note] > Note > Because the xml:space attribute is not prohibited on elements that allow > non-XLIFF namespace attributes, <source> or <target> elements that do > not have an xml:space attribute could inherit an xml:space value. > If an ancestor element has an xml:space attribute, the <source> or > <target> would inherit that value. Sounds fine to me. > As for your second point: > ... > I think you mean that elements who do not set their own xml:space, > who descend from elements which do have xml:space set to something, > have the same value as that ancestor. Yes. > But I think if xml:space was not set on any ancestor, the Default value > is still “default” for these <source> and <target> elements. > Therefore, I think the proposed solution above satisfies this point as well. Wouldn't be me more consistent to do like David did for srcDir and trgDir and indicates that the default value depends on the parent/ancestor? 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 Bryan, > The point I struggled to make was that we still need to account > for the more common scenario, that in which no xml:space attribute > occurs on the parent/ancestor - and no xml:space attribute occurs > on the <source> and <target> > ... > I don't recall the TC discussion about xml:space. But I think our whole > reason for including the section in the spec is that in the absence > of an explicit xml:space="preserve" on <source> or <target> is > that we want the value to be "default." > > If we say "the default value depends on the parent/ancestor" we are > not making our point. We do have a section on White-space. So maybe something like this: [[ Default value: For data: 'preserve'. Note also that the 'default' value is to be interpreted as 'preserve' for the data content (See section 4.7.5 White Spaces). Other elements: The default value is inherited from the closest ancestor defining xml:space. If no ancestor specify xml:space the default is 'default'. ]] -ys

Hi Yves, Your words sound fine to me. But I'm still just a little confused. I thought 4.7.5 White Spaces was section on white-spaces. Where in the spec are you proposing to put the new words? - Bryan ________________________________________ From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Yves Savourel [ysavourel@enlaso.com] Sent: Sunday, January 05, 2014 9:27 AM To: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Hi Bryan, > The point I struggled to make was that we still need to account > for the more common scenario, that in which no xml:space attribute > occurs on the parent/ancestor - and no xml:space attribute occurs > on the <source> and <target> > ... > I don't recall the TC discussion about xml:space. But I think our whole > reason for including the section in the spec is that in the absence > of an explicit xml:space="preserve" on <source> or <target> is > that we want the value to be "default." > > If we say "the default value depends on the parent/ancestor" we are > not making our point. We do have a section on White-space. So maybe something like this: [[ Default value: For data: 'preserve'. Note also that the 'default' value is to be interpreted as 'preserve' for the data content (See section 4.7.5 White Spaces). Other elements: The default value is inherited from the closest ancestor defining xml:space. If no ancestor specify xml:space the default is 'default'. ]] -ys --------------------------------------------------------------------- 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

Sorry for being unclear: The possible text was for the xml:space attribute definition. -ys
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Schnabel, Bryan S Sent: Sunday, January 5, 2014 9:15 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Hi Yves, Your words sound fine to me. But I'm still just a little confused. I thought 4.7.5 White Spaces was section on white-spaces. Where in the spec are you proposing to put the new words? - Bryan ________________________________________ From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Yves Savourel [ysavourel@enlaso.com] Sent: Sunday, January 05, 2014 9:27 AM To: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Hi Bryan, > The point I struggled to make was that we still need to account for > the more common scenario, that in which no xml:space attribute occurs > on the parent/ancestor - and no xml:space attribute occurs on the > <source> and <target> ... > I don't recall the TC discussion about xml:space. But I think our > whole reason for including the section in the spec is that in the > absence of an explicit xml:space="preserve" on <source> or <target> is > that we want the value to be "default." > > If we say "the default value depends on the parent/ancestor" we are > not making our point. We do have a section on White-space. So maybe something like this: [[ Default value: For data: 'preserve'. Note also that the 'default' value is to be interpreted as 'preserve' for the data content (See section 4.7.5 White Spaces). Other elements: The default value is inherited from the closest ancestor defining xml:space. If no ancestor specify xml:space the default is 'default'. ]] -ys --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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

Yves, When you say "For data," do you intend this to be a generic term that covers things like codes and original data (i.e., source/target text and the inlines that cover those data types)? Or do you mean <data>? If the latter, why not include <sc>, <ec>, and <ph>, as stated in 4.7.5? So for "4.3.2.2 xml:space" (a subsection under the 4.3.2 XML namespace section) would the following be better to support your proposal? Change from: Default value: default To: Default value: For <sc>, <ec>, <ph> and <data>: 'preserve'. Note also that the 'default' value is to be interpreted as 'preserve' for the data content (See section 4.7.5 White Spaces). Other elements: The default value is inherited from the closest ancestor defining xml:space. If no ancestor specify xml:space the default is 'default'. And for "4.7.5 White Spaces" no change required? Thanks, Bryan
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Sunday, January 05, 2014 9:01 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Sorry for being unclear: The possible text was for the xml:space attribute definition. -ys
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Schnabel, Bryan S Sent: Sunday, January 5, 2014 9:15 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Hi Yves, Your words sound fine to me. But I'm still just a little confused. I thought 4.7.5 White Spaces was section on white-spaces. Where in the spec are you proposing to put the new words? - Bryan ________________________________________ From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Yves Savourel [ysavourel@enlaso.com] Sent: Sunday, January 05, 2014 9:27 AM To: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Hi Bryan, > The point I struggled to make was that we still need to account for > the more common scenario, that in which no xml:space attribute occurs > on the parent/ancestor - and no xml:space attribute occurs on the > <source> and <target> ... > I don't recall the TC discussion about xml:space. But I think our > whole reason for including the section in the spec is that in the > absence of an explicit xml:space="preserve" on <source> or <target> is > that we want the value to be "default." > > If we say "the default value depends on the parent/ancestor" we are > not making our point. We do have a section on White-space. So maybe something like this: [[ Default value: For data: 'preserve'. Note also that the 'default' value is to be interpreted as 'preserve' for the data content (See section 4.7.5 White Spaces). Other elements: The default value is inherited from the closest ancestor defining xml:space. If no ancestor specify xml:space the default is 'default'. ]] -ys --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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 Bryan, > When you say "For data," do you intend this to be a > generic term that covers things like codes and original data... Sorry, no. I meant only the <data> element. That is the only element with the 'preserve' behavior requirement in the White spaces section. > And for "4.7.5 White Spaces" no change required? I don't think so. Nobody commented on that section., so I assume it is fine as it is. Thanks, -yves

Thanks Yves. So in 4.7.5 the processing requirement says: "For the elements <sc>, <ec>, <ph> and <data>: The white spaces of their content MUST be preserved in all cases, even if the value for xml:space is set or inherited as default." Is that still okay, and does that not conflict with your statement: > I meant only the <data> element. > That is the only element with the > 'preserve' behavior requirement in the > White spaces section. (sorry for these questions - but I think we are pretty close to being able to word the CFD on this one, with these answers)
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Monday, January 06, 2014 10:35 AM To: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Hi Bryan, > When you say "For data," do you intend this to be a generic term that > covers things like codes and original data... Sorry, no. I meant only the <data> element. That is the only element with the 'preserve' behavior requirement in the White spaces section. > And for "4.7.5 White Spaces" no change required? I don't think so. Nobody commented on that section., so I assume it is fine as it is. Thanks, -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

Actually, there is a request for change in the White Space section: I forgot about it: https://lists.oasis-open.org/archives/xliff/201312/msg00173.html So: "For the elements <sc>, <ec>, <ph> and <data>: The white spaces of their content MUST be preserved in all cases, even if the value for xml:space is set or inherited as default." Would become: "For the element <data>: The white spaces of its content MUST be preserved in all cases, even if the value for xml:space is set or inherited as default." -ys
Original Message----- From: Schnabel, Bryan S [ mailto:bryan.s.schnabel@tektronix.com ] Sent: Monday, January 6, 2014 1:28 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Thanks Yves. So in 4.7.5 the processing requirement says: "For the elements <sc>, <ec>, <ph> and <data>: The white spaces of their content MUST be preserved in all cases, even if the value for xml:space is set or inherited as default." Is that still okay, and does that not conflict with your statement: > I meant only the <data> element. > That is the only element with the > 'preserve' behavior requirement in the White spaces section. (sorry for these questions - but I think we are pretty close to being able to word the CFD on this one, with these answers)
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Monday, January 06, 2014 10:35 AM To: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Hi Bryan, > When you say "For data," do you intend this to be a generic term that > covers things like codes and original data... Sorry, no. I meant only the <data> element. That is the only element with the 'preserve' behavior requirement in the White spaces section. > And for "4.7.5 White Spaces" no change required? I don't think so. Nobody commented on that section., so I assume it is fine as it is. Thanks, -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

Perfect! Thanks Yves. I think I have everything I need for the CFD for 127. I will send it shortly. Also, since your request for the change to 4.7.5 is more than a week old, and has not gotten any negative response, I will add it to the tracker, assign it to myself, and send out a CFD for it also. Thanks, Bryan
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Monday, January 06, 2014 12:39 PM To: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Actually, there is a request for change in the White Space section: I forgot about it: https://lists.oasis-open.org/archives/xliff/201312/msg00173.html So: "For the elements <sc>, <ec>, <ph> and <data>: The white spaces of their content MUST be preserved in all cases, even if the value for xml:space is set or inherited as default." Would become: "For the element <data>: The white spaces of its content MUST be preserved in all cases, even if the value for xml:space is set or inherited as default." -ys
Original Message----- From: Schnabel, Bryan S [ mailto:bryan.s.schnabel@tektronix.com ] Sent: Monday, January 6, 2014 1:28 PM To: Yves Savourel; xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Thanks Yves. So in 4.7.5 the processing requirement says: "For the elements <sc>, <ec>, <ph> and <data>: The white spaces of their content MUST be preserved in all cases, even if the value for xml:space is set or inherited as default." Is that still okay, and does that not conflict with your statement: > I meant only the <data> element. > That is the only element with the > 'preserve' behavior requirement in the White spaces section. (sorry for these questions - but I think we are pretty close to being able to word the CFD on this one, with these answers)
Original Message----- From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Monday, January 06, 2014 10:35 AM To: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space) Hi Bryan, > When you say "For data," do you intend this to be a generic term that > covers things like codes and original data... Sorry, no. I meant only the <data> element. That is the only element with the 'preserve' behavior requirement in the White spaces section. > And for "4.7.5 White Spaces" no change required? I don't think so. Nobody commented on that section., so I assume it is fine as it is. Thanks, -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 --------------------------------------------------------------------- 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

Yves, Bryan, I agree that the default for xml:space is the value inherited from the parent. This is how the behavior is defined in the xml spec. However I believe that we have a more profound issue with the attributes from the xml namespace, i.e. that they have core status at the explicitly specified locations. But they can also be set at extension points. Now, for the inheritance it does not matter if the value was set at an extension point or core location and this can lead to unexpected behabior IMHO, as the value can be flipped inadvertently by adding or removing extensions. I was contemplating several ugly solutions for this issue before the Xmas break, including forbidding setting those attributes where they are not explicitly allowed. Now, I believe that we should explicitly include the xml namespace attributes as core at all elements that are extensible by other namespaces to avoid the mixed core/extension behavior of the attributes. The other way out would be to have xlf:space and xlf:lang and these would be automatically disallowed at the extension points by virtue of the ‘other‘ wildcard. Nevertheless, I believe that the former is cleaner and the right thing to do Cheers dF dF is AFK, so that this had to be typed on his tough phone.. Call me at +353860222158 if this answer does not seem sufficient ;) On Jan 6, 2014 6:34 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi Bryan, > When you say  "For data," do you intend this to be a > generic term that covers things like codes and original data... Sorry, no. I meant only the <data> element. That is the only element with the 'preserve' behavior requirement in the White spaces section. > And for "4.7.5 White Spaces" no change required? I don't think so. Nobody commented on that section., so I assume it is fine as it is. Thanks, -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

David,   I have no objection to your proposal. But I don’t understand the advantage of explicitly including the XML namespace attributes as core vs. adding them via extensibility.   I will hold off from sending my CFD for 127 and 150 in favor of addressing them at the TC meeting tomorrow. Hopefully we will be able to put these, along with Fragment Identification, to a roll call ballot solution.   Thanks,   Bryan   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of David Filip Sent: Monday, January 06, 2014 1:12 PM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space)   Yves, Bryan, I agree that the default for xml:space is the value inherited from the parent. This is how the behavior is defined in the xml spec. However I believe that we have a more profound issue with the attributes from the xml namespace, i.e. that they have core status at the explicitly specified locations. But they can also be set at extension points. Now, for the inheritance it does not matter if the value was set at an extension point or core location and this can lead to unexpected behabior IMHO, as the value can be flipped inadvertently by adding or removing extensions. I was contemplating several ugly solutions for this issue before the Xmas break, including forbidding setting those attributes where they are not explicitly allowed. Now, I believe that we should explicitly include the xml namespace attributes as core at all elements that are extensible by other namespaces to avoid the mixed core/extension behavior of the attributes. The other way out would be to have xlf:space and xlf:lang and these would be automatically disallowed at the extension points by virtue of the ‘other‘ wildcard. Nevertheless, I believe that the former is cleaner and the right thing to do Cheers dF dF is AFK, so that this had to be typed on his tough phone.. Call me at +353860222158 if this answer does not seem sufficient ;) On Jan 6, 2014 6:34 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi Bryan, > When you say  "For data," do you intend this to be a > generic term that covers things like codes and original data... Sorry, no. I meant only the <data> element. That is the only element with the 'preserve' behavior requirement in the White spaces section. > And for "4.7.5 White Spaces" no change required? I don't think so. Nobody commented on that section., so I assume it is fine as it is. Thanks, -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,   Same for me: I have no objection to the change, but I don’t see many advantages to it.   The xml:space attribute behavior is an XML behavior, not something XLIFF should spend time/pages to define (aside from the meaning of ‘default’ when needed).   I’m guessing you want the implementers to notice the potential issues and be sure they implement the behavior properly. Personally I think the new definition in xml:space is enough. But it’s just one opinion.   Cheers, -ys     From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com] Sent: Monday, January 6, 2014 2:30 PM To: David Filip; Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space)   David,   I have no objection to your proposal. But I don’t understand the advantage of explicitly including the XML namespace attributes as core vs. adding them via extensibility.   I will hold off from sending my CFD for 127 and 150 in favor of addressing them at the TC meeting tomorrow. Hopefully we will be able to put these, along with Fragment Identification, to a roll call ballot solution.   Thanks,   Bryan   From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of David Filip Sent: Monday, January 06, 2014 1:12 PM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space)   Yves, Bryan, I agree that the default for xml:space is the value inherited from the parent. This is how the behavior is defined in the xml spec. However I believe that we have a more profound issue with the attributes from the xml namespace, i.e. that they have core status at the explicitly specified locations. But they can also be set at extension points. Now, for the inheritance it does not matter if the value was set at an extension point or core location and this can lead to unexpected behabior IMHO, as the value can be flipped inadvertently by adding or removing extensions. I was contemplating several ugly solutions for this issue before the Xmas break, including forbidding setting those attributes where they are not explicitly allowed. Now, I believe that we should explicitly include the xml namespace attributes as core at all elements that are extensible by other namespaces to avoid the mixed core/extension behavior of the attributes. The other way out would be to have xlf:space and xlf:lang and these would be automatically disallowed at the extension points by virtue of the ‘other‘ wildcard. Nevertheless, I believe that the former is cleaner and the right thing to do Cheers dF dF is AFK, so that this had to be typed on his tough phone.. Call me at +353860222158 if this answer does not seem sufficient ;) On Jan 6, 2014 6:34 PM, "Yves Savourel" < ysavourel@enlaso.com > wrote: Hi Bryan, > When you say  "For data," do you intend this to be a > generic term that covers things like codes and original data... Sorry, no. I meant only the <data> element. That is the only element with the 'preserve' behavior requirement in the White spaces section. > And for "4.7.5 White Spaces" no change required? I don't think so. Nobody commented on that section., so I assume it is fine as it is. Thanks, -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