[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=64058#comment-64058 ] 

David Filip commented on XLIFF-9:
---------------------------------

Felix, Yves, I agree that usage of the original w3c namespace would make the categories w/o global pointing capability somewhat better accessible to generic ITS processors..

I see however two big blockers that IMHO and AFAIK prevent switching to the original W3C namespace:
1) the semantics of the attributes in the original namespace is different. The attributes defined do not apply to the contents of pseudo-spans formed by <sc/>/<ec/> pairs but to the empty content of each opening <sc/>.

2) We define XLIFF-defined in "Key concepts" of the XLIFF 2.0 and XLIFF 2.1 specifications via the URN prefix urn:oasis:names:tc:xliff:, but the W3C ITS namespace is identified by a URL..
By adding the URL namespace to the XLIFF-defined definition, we are affecting the ability of core-only agents to identify ITSM data as module data rather than extension data and I like this even less than 1)

> 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)