OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

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

Felix, thanks for checking that only the two datacats we alerady have child issues for need to fall back on the itsm namespace.
WRT the link, it is the csprd01 link and that has to remain immutable for the record as to what exactly was reviewed in the 1st public review last year.
This is the link to the latest version of the Editors' draft:
http://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-21/xliff-core-v2.1.pdf [currently wd02 from 17th January]
The wd02 will turn into the officially published csprd02 version hopefully next week.
The Editors' draft was last printed on 17th January, this means that in that printout, all ITS datacats are using the W3C ITS namespace including the ones that shouldn't.
The resolutions for https://issues.oasis-open.org/browse/XLIFF-18 and https://issues.oasis-open.org/browse/XLIFF-19 that are the relevant child issues are already on the SVN prose but not yet printed. They are also implemented in the core, its and itsm xsds. sch and NVDL changes are pending
On Monday, I will print the wd02 that will be proposed as csprd02 in the next meeting..  

> 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, validation artifacts
>    Affects Versions: 2.1_csprd01
>         Environment: https://lists.oasis-open.org/archives/xliff-comment/201610/msg00020.html
>            Reporter: Yves Savourel
>            Assignee: Soroush Saadatfar
>              Labels: work_required
>             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)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]