[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Re: Ownership of the xml:space issue?
We should just set preserve as a fixed value for <data>.
The idea is to always preserve the whitespace there.
-ys
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: Thursday, January 16, 2014 4:17 AM
To: Schnabel, Bryan S
Cc: xliff@lists.oasis-open.org; Dr. David Filip (David.Filip@ul.ie)
Subject: [xliff] Re: Ownership of the xml:space issue?
Thanks for summarizing this, Bryan,
below s till a few clarifications
Unless we uncover a controversy due to my clarifications, I can implement this by the end of this week.
Apparently, this only adressed the white space part of the xml namespace issue. I will send a separate e-mail on xml:lang, which seems even more tricky to me..
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 Wed, Jan 15, 2014 at 9:42 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com> wrote:
David,
I think we said you would take over ownership of the xml:space issue once it became an editorial issue? Not trying to dodge work, so if this is not true I can make the updates.
I think four things need to be done based on our ballot, and on the CFDs for 127 and 150 (where the CFD ends and the ballot begins is a little foggy – so I think we should just reference the meeting minutes and ballot results in the tracker – up to you).
1. Remove xml:space from the attribute list of <source> (4.2.2.12) and <target> (4.2.2.13). Also notice there is a constraint on <target> that will need to be edited.
Clear
2. Add OPTIONAL xml:space to <xliff> (4.2.2.1), <file> (4.2.2.2), <group>(4.2.2.4), and unit (4.2.2.5).
Clear
3. Change the Default value in 4.3.2.2 to (https://lists.oasis-open.org/archives/xliff/201401/msg00016.html):
[[
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).
This seems strange, see below
Other elements:
The default value is inherited from the closest ancestor defining xml:space. If no ancestor specify xml:space the default is 'default'.
]]
I agree with this materially, but as Yves, said the inheritance should be perhaps defined in a recursive way, same as for the other falgs we have, e.g. translate, or canResegment
default for <xliff>
inherited from parent on <file>
inherited from parent on <group>
inherited from parent on <unit>
And (https://lists.oasis-open.org/archives/xliff/201401/msg00019.html) change the Used in from <source>, <target> to <xliff>, <file>, <group>, <unit>
Clear
4. Change 4.7.5
- from “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.”
- to “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.”
The value cannot be inherited as default, as the default is set as "preserve", i.e. taken out of the inheritance chain.
Now, if users, still have the option to set the white space handling on data to "default", isn't it possible that they mean it?
If no, there should be a Constraint on the data element saying that the xml:space value MUST NOT be set to "default".
Here we can then have an (informative) Warning saying that the value of the xml:space value has been constrained to "preserve" on the data element.
Or nothing, as Yves was advocating against redundancy in the spec.
Please let me know if you want to make the changes, or if you want me to.
Thanks,
Bryan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]