[OASIS Issue Tracker] (XLIFF-9) Use (also) the normal ITS namespace in the ITSM module

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/XLIFF-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64277#comment-64277 ] 

Felix Sasaki commented on XLIFF-9:
----------------------------------

Hi David,

on 
" You can't really say that the attributes declared in the w3c namespace apply to XLIFF-defined pseudospans. "

using such attributes at XLIFF pseudospans does not break an ITS processor. The ITS processor will just "see" nothing for sm/em. On the other hand, as you acknowledged, it will be easier for an ITS processor on mrk / wellformed spans with the ITS namespace.

I understand what you say about the XLIFF semantics. But there also the implementers point of view, from both the XLIFF and ITS perspective - see above, and what Yves said:

"Maybe I'm missing something, but I cannot see an advantage in using ITSM over ITS, but I can see the reverse."

It may be hard to do the best both from the implementers and from the spec point of view.

On validation, you wrote
"How should the module data be validated when based on the w3c namespace? 
Would we be still be able to point from the catalog and NVDL to our xsd that is used as the baseline for the module Schematron, or would we be forced to use the w3c hosted (normative) RNG or (informative) xsd?"

The ITS (2.0) schemas are not normative. They are informative and can be copied / re-used as we like. This is what also docbook 5.1 does, see
http://docs.oasis-open.org/docbook/docbook/v5.1/cos01/docbook-v5.1-cos01.html#s.docbook

> Use (also) the normal ITS namespace in the ITSM module
> ------------------------------------------------------
>
>                 Key: XLIFF-9
>                 URL: https://issues.oasis-open.org/browse/XLIFF-9
>             Project: OASIS XML Localisation Interchange File Format (XLIFF) TC
>          Issue Type: New Feature
>          Components: ITS Module
>    Affects Versions: 2.1_csprd01
>         Environment: https://lists.oasis-open.org/archives/xliff-comment/201610/msg00020.html
>            Reporter: Yves Savourel
>            Assignee: Felix Sasaki
>              Labels: request_tc_discussion
>             Fix For: 2.1_csprd02
>
>
> Looking at the rules files for ITSM, we can see there are several data categories that cannot be mapped by rules because they do not
> have pointer attributes available.
> - Localization Quality Issues
> - Localization Quality Rating
> - Provenance
> - MT Confidence
> This means a pure ITS processor cannot process an XLIFF document and get any data for those data categories.
> This would be resolved if the namespace was ITS' rather than the ITSM (ITS Module) namespace.
> I believe we selected early on to go with ITSM even for the data categories defined from scratch because of the <sm/> case where the
> semantics need to be adjusted. Since, we establish (I think) that the <sm/> case is such that ITS processors cannot really resolve
> it anyway.
> In other words, the <sm/> case is hopeless if you are not an XLIFF processor, whether you use ITS or ITSM, and XLIFF processors do
> treat <sm/> in a special way in the case of ITSM. They could do the same for ITS.
> Hence, it seems all the data categories that ITSM implements 'from scratch' could be in the normal ITS namespace, and work for both
> XLIFF and ITS processors.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)