W3C home > Mailing lists > Public > public-i18n-its-ig@w3.org > October 2014

Re: [xliff] ITS: Preserve space and Language Information

From: Dr. David Filip <David.Filip@ul.ie>
Date: Fri, 24 Oct 2014 18:55:55 +0100
Message-ID: <CANw5LK=xdnBMRUbqeTnWt-md5VdDtPbef=2NSm78dQq_2Ama+g@mail.gmail.com>
To: Yves Savourel <ysavourel@enlaso.com>
CC: XLIFF Main List <xliff@lists.oasis-open.org>, public-i18n-its-ig <public-i18n-its-ig@w3.org>
Thanks, Yves, inline

On Fri, Oct 24, 2014 at 3:31 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

> Going from a structural element to an inline one in the Terminology case
> is easy: you don't lose anything.
> But forcing some inline formatting information to drive segmentation is
> completely different and very restrictive.
> In addition to losing granularity you also assume the segmentation is done
> by the extractor agent.
I don't understand what losing granularity means, as I understand
granularity, you get more of it IMHO, if you make whitespace handling and
language info structural..
Anyways, I see your point that it is not ideal to force Extractors to
segment in order to handle a relatively frequent extraction issue.
And i do see value in deferring the segmentation issues by putting the its
info inline..

> I see plenty of technical documents where inline formatting mixes spans of
> true text with fixed-space sections. Elements like <code>, <var>, <kbd>,
> etc. in HTML (and their counterparts in DITA, DocBook, etc.) are examples
> of such spans where the style often requires preserving the spaces. There
> is no way we can reasonably use segmentation to apply that information.
> The bottom line is that if we didn't have <sm/> we would not have this
> discussion and everyone would see xml:space and xml:lang as perfectly
> natural in <mrk>. This tells me the issue is how to represent those two
> features with <sm/>.

> Trying to rationalize how we can avoid inline cases is just wishful
> thinking.
> Ideally what we should have done in 2.0 was to allow xml:lang and
> xml:space in <mrk> and declare XLIFF Core attributes ‘space’ and ‘lang’ for
> <sm/> to work around the scope issue.
> But we are at 2.1 now, and we can't modify the Core.
Yes, we cannot

> So, in my opinion, using the ITS module to get an inline solution seems to
> be the best we can do now.
I agree
And I think it is actually better to have the inline semantics of these
attributes defined in one module..
So I am OK with defining those two  attributes in the its module namespace
Still, as I said in the other thread, I'd keep the informative description
of what you can do with core only, of course moved into the partial support


Dr. David Filip
OASIS XLIFF TC Secretary, Editor, and Liaison Officer
University of Limerick, Ireland
telephone: +353-6120-2781
*cellphone: +353-86-0222-158*
facsimile: +353-6120-2734
mailto: david.filip@ul.ie
Received on Friday, 24 October 2014 17:57:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:05:52 UTC