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

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

@Felix 1) does change with ITSM, you are confusing two things there.. I acknowledged that ITS processors get somewhat more access to ITS data in XLIFF if the original w3c module is used, but 1) is about semantic mismatch.. You can't really say that the attributes declared in the w3c namespace apply to XLIFF-defined pseudospans. If we decide to go for that, we would need to cheat on this one..

Yves is correctly identifying the definition I meant. Of course URN is just a kind of URL but that's not the point, we would be changing the definition that core only agents use to identify protected XLIFF-defined namespaces. This is arguably core impact that we promised not to do in dot releases..
@Yves, I think that you can't be serious saying that people can delete module data anyways.. That's not the point. People can do lot of things, the point is that the specification prohibits deletion of unsupported XLIFF-defined data and it only discourages deletion of unsupported extension data. The whole point of the exercise (making ITS functionality available through an XLIFF-defined module) is to provide 
A) guaranteed roundtrip protection
B) ensure that the categories apply correctly to pseudospans formed by atomic markers
it might be true that you can get away with well-formed markers most of the time, but we guarantee the equivalnce of psuedospans with well-formed spans and any agent in the chain can simply recast everything in psudospans even if well-formed spans are possible. We had discussed (in the inline SC for the XLIFF 2.0 design) manadting of the well-formed spans if possible but decided not to go that way.. If I remember correctly you and Fredrik even suported not having well-formed spans inline at all, since pseudospans are expressive enough (which is true).

Despite the above two principal issues that were NOT addressed by your responses, there are more practical considerations and potentially big ramifications for the advanced validation.

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?
 
It is a huge change of something that we agreed on for good reasons a very long time ago and I simply don't think that the small benefits (the two of you outlined and I fully acknowledged) outweigh the principal and practical drawbacks of doing the change.. Of course we can do big changes and go for csprd02, just that I don't think we should do this huge change

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