[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 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
Clear
This seems strange, see below
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>
Clear
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]