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

Good point about "itx".

"xits" or anything is fine with me.

 

-ys

 

 

From: Felix Sasaki [mailto:felix@sasakiatcf.com] 
Sent: Tuesday, October 28, 2014 4:35 PM
To: Yves Savourel
Cc: Dr. David Filip; XLIFF Main List; public-i18n-its-ig
Subject: Re: [xliff] ITS: Preserve space and Language Information

 

 

Am 28.10.2014 um 16:29 schrieb Yves Savourel <ysavourel@enlaso.com <mailto:ysavourel@enlaso.com> >:





You mean a different namespace prefixes I assume.

 

Yes, sorry for being unclear.





 

My understanding though is that we would never have the W3C ITS namespace in an XLIFF 2 file because it'd be officially supported
through the ITS module, which would use a single separate namespace.

 

I suppose one cannot prevent someone the use the W3C ITS namespace on extension points, but it would have to be for data categories
not supported by the ITS module, as one of the XLIFF 2 PRs is to not have an extension implementing the same thing as an official
module ( <http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#d0e10828>
http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#d0e10828)

 

I suppose we could use "itx" or "xits" or "itsx" if we decide to use a prefix different from "its".

 

We used itsx for ITS (not xliff) extension examples before, see

 

http://www.w3.org/2008/12/its-extensions

 

again it does not matter for processing but "xits" then may help to differentiate things.

 

- Felix





 

-ys

 

From: Felix Sasaki [ <mailto:felix@sasakiatcf.com> mailto:felix@sasakiatcf.com] 
Sent: Tuesday, October 28, 2014 4:18 PM
To: Dr. David Filip
Cc: Yves Savourel; XLIFF Main List; public-i18n-its-ig
Subject: Re: [xliff] ITS: Preserve space and Language Information

 

Thanks for your clarifications, David and Yves. Would it make sense to use a different namespace in the examples? It does not matter
for software but for readers of the example.

 

Actually it may also be relevant for software if there is a case to have an W3C ITS attribute and the OASIS ITS attribute at the
same element - you would need different namespaces.

 

Best,

 

Felix

 

Am 28.10.2014 um 15:10 schrieb Dr. David Filip < <mailto:David.Filip@ul.ie> David.Filip@ul.ie>:






I believe we are talking about the OASIS hosted  

*       urn:oasis:names:tc:xliff:its:2.1

XLIFF TC recorded consensus to use one OASIS hosted namespace for all that is needed for the mapping..

Also in the last ITS IG call we said that it is better to have all attributes defined in the XLIFF TC prefixed namespace for various
reasons..

 

The reason most relevant here is that the scope of the XLIFF defined its attributes will include spans delimited by empty boundary
markers apart from well formed spans.

 

This will be the case also for its:space and its:lang

 

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> http://www.cngl.ie/profile/?i=452

mailto:  <mailto:david.filip@ul.ie> david.filip@ul.ie

 

On Tue, Oct 28, 2014 at 6:19 PM, Felix Sasaki < <mailto:fsasaki@w3.org> fsasaki@w3.org> wrote:

HI Yves, David, all,

 

one clarification question: Yves used in his examples the its:lang and its:space attributes. Is the idea to add things to the OASIS
to be hosted ITS namespace or to add attributes to the W3C ITS namespaces? In the past we discussed the former.

 

Best,

 

Felix

 

Am 24.10.2014 um 10:55 schrieb Dr. David Filip < <mailto:David.Filip@ul.ie> David.Filip@ul.ie>:






Thanks, Yves, inline

 

On Fri, Oct 24, 2014 at 3:31 PM, Yves Savourel < <mailto:ysavourel@enlaso.com> 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/>.

Yes 

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 section..

 

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> http://www.cngl.ie/profile/?i=452

mailto:  <mailto:david.filip@ul.ie> david.filip@ul.ie