I agree with all what Yves wrote. - Felix Am 09.08.2016 um 22:27 schrieb Yves Savourel <
ysavourel@enlaso.com >: Hi David, all, Ø So to sum up I am fine with either allowing the itsm:rulesRef on xliff or not having it at all. Good: let’s not have it then :) Ø Still we will need to describe the canonical way how to include <its:rules> as a guidance (informative rather than normative), otherwise people will invent all sort of crazy stuff that we won't like to see.. I honestly think you are making this a lot more complicated than it should to be. How an ITS processor processes an XML file is an ITS issue. The XLIFF TC just provides the rules file for the ITS mapping in XLIFF 2.x, just like we have rules files for other formats. We don’t go tell DITA users how they should set up the ITS rules for DITA, why would we have to do it for XLIFF? IMHO there is plenty of work to do already: let’s not add things that we not really needed. Ø 1) Do you agree that the module's schematron file is the ideal location? Maybe, but a separate rules file would work as well IMO. Ø 2) Do we want to mandate the one rules file or would we allow to make knock offs? Like subsetting the rules if people don't use all data categories. Not sure how else the rules set could deviate, probably not much Not sure why people would do anything with the rules file (or that you can allow or disallow them to do anything). We just provide the rules file. Ø 3) Do we want to mandate the rules file to be a part of a specific TC guaranteed validation artifact such as a sch or xsd file? Or do we want to provide the standalone file with <its:rules> as root? Or do we want just to describe the structure and let people use it wherever? That would actually allow use of internal included rules.. which, as we agreed in October 2014, wasn't ideal I’m again not sure I understand. The rules files is processed by the ITS processor, following ITS PRs. It can be validated like any other ITS rules file. All that is ITS-specific and has nothing to do with XLIFF. Maybe I’m not understanding your concerns, but things look very simple to me: We provide the rules file (like for DITA, etc.). The ITS processors deal with it the same way they deal with any rules file. I hope that helps. Cheers, -ys From: David Filip [ mailto:
david.filip@adaptcentre.ie ] Sent: Tuesday, August 9, 2016 1:16 PM To: Felix Sasaki <
felix@sasakiatcf.com > Cc: Yves Savourel <
ysavourel@enlaso.com >; XLIFF Main List <
xliff@lists.oasis-open.org > Subject: Re: [xliff] preparing csd01/csprd01 - Question where to allow ITSM elements and attributes Felix, Yves, all, I don't feel strongly about having the module guaranteed pointer. I proposed myself not caring as an option.. Still I think that you dismissed the itsm:rulesRef too fast.. I agree with Yves that a generic ITS Processor will not understand the itsm:rulesRef and the XLIFF Agent supporting the module will not need it. But XLIFF is roundtrip oriented and the tool restoring the generic information on the file extension point doesn't need to be the same tool as the generic ITS processor consuming it. In fact I totally don't expect it to be the same tool. First I thought about making a normative MUST PR for ITSM Writers about expanding the itsm:rulesRef into the extended annotation on file, then I thought it would be way over the top ;-) to try and mandate an extension structure by Module PRs, so I went for the Note (informative by definition) to explain the use case, maybe the note should explicitly say that it's a scenario where the XLIFF Agent restores the information from the guaranteed point. I also placed this guidance in a note because this is a workflow hint and we agreed not to prescribe specific workflows normatively. I think that the guaranteed pointer is rather harmless, and I am happy to remove the Constraint making it REQUIRED when the XLIFF Document contains ITS Module defined data if you think it would reduce the implementation burden. I think there is some positive value in having the protected pointer on a prominent place. And I don't take the argument that the case of a generic ITS Processor will be rare. We are trying to make a future proof standard. And we are in relatively early adoption stages for both ITS 2 and XLIFF 2. I believe that by making the URI protected we are helping adoption in large distributed corporate architectures. I am thinking about ITS processors extracting data for analytics from large XLIFF corpora without being otherwise XLIFF aware, I think that this is a big future scenario. MT Confidence, LQI, LQR, are just a few of the data categories that people would want to extract from XLIFF for business analytic purposes. So to sum up I am fine with either allowing the itsm:rulesRef on xliff or not having it at all. Still we will need to describe the canonical way how to include <its:rules> as a guidance (informative rather than normative), otherwise people will invent all sort of crazy stuff that we won't like to see.. There are a few more open questions that might have influence on whether to have or not the protected rules pointer. 1) Do you agree that the module's schematron file is the ideal location? 2) Do we want to mandate the one rules file or would we allow to make knock offs? Like subsetting the rules if people don't use all data categories. Not sure how else the rules set could deviate, probably not much 3) do we want to mandate the rules file to be a part of a specific TC guaranteed validation artifact such as a sch or xsd file? Or do we want to provide the standalone file with <its:rules> as root? Or do we want just to describe the structure and let people use it wherever? That would actually allow use of internal included rules.. which, as we agreed in October 2014, wasn't ideal Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Tue, Aug 9, 2016 at 6:07 AM, Felix Sasaki <
felix@sasakiatcf.com > wrote: Am 08.08.2016 um 20:05 schrieb Yves Savourel <
ysavourel@enlaso.com >: Hi David, Felix, all, So an ITS processor needs to know about the rules to be able to process the ITSM module. But I’m doubt very much it is worth doing anything about it from the ITSM viewpoint (aside providing the rules file). - The ITS processor cannot understand itsm:rulesRef - The XLIFF+ITMS processor does not need itsm:rulesRef So why we would have it anywhere? The spec text would offer the following reason: “The rulesRef attribute is intended as a protected backup location for the pointer to the universal XLIFF 2 ITS rules file for generic ITS Processors. In case the rules pointer is missing for any reason at the <file> extension point, the IRI value of the rulesRef attribute needs to be used to restore the information at the extension point as follows.” I think that is way over the top :) If a processor is capable of processing rulesRef, it might as well knows where to get the rules file (and does not really need a pointer to it). Extremely few users are going to process an XLIFF file with a pure ITS processor. I don’t think we should complicate things with a specific attribute like this to do it. I very much prefer this option: >> We could also not care if the its: pointer or <its:rules> are in any way included >> in the XLIFF … +1. - Felix The ITS processor doesn’t need anything in the XLIFF file and can use a tool-specific mechanism to associate the XLIFF document with the ITS rules file. Most ITS processors out there have such mechanism available and that is, by far, the most widespread way to use associate ITS rules to XML files. Cheers, -yves From: David Filip [ mailto:
david.filip@adaptcentre.ie ] Sent: Monday, August 8, 2016 7:27 PM To: Felix Sasaki <
felix@sasakiatcf.com > Cc: Yves Savourel <
ysavourel@enlaso.com >; XLIFF Main List <
xliff@lists.oasis-open.org > Subject: Re: [xliff] preparing csd01/csprd01 - Question where to allow ITSM elements and attributes Felix, Yves, all, I created an itsm:rulesRef attribute as proposed above.
http://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-21/attributes/itsm/itsm_rulesRef.xml The example included in the attribute file assumes that the ITS rules will be located in the itsm.sch file that will be distributed in the schemas folder with the standard. If this seems fine, I would allow itsm: namespace on <xliff> and change the text spec to indicate that the XLIFF specific <its:rules> will be part of the module's schematron file. Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Mon, Aug 8, 2016 at 5:18 PM, David Filip <
david.filip@adaptcentre.ie > wrote: Or even more elegant, the rules could be included in the module xsd or sch Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Mon, Aug 8, 2016 at 5:00 PM, David Filip <
david.filip@adaptcentre.ie > wrote: Felix, all, some more thinking on the mechanics of the external rules inclusion and parsing I would go for the external file as in the example 19
https://www.w3.org/TR/its20/examples/xml/EX-link-external-rules-4.xml , an xml with the <its:rules> as the root element.. Anyways, we have an interesting issue with defining the generic ITS functionality If we introduce <itsm:rules> the generic ITS processors wouldn't strictly speaking know what to do with it If we use <its:rule> we cannot effectively protect it as a module feature without declaring xmlns:its =
http://www.w3.org/2005/11/its an XLIFF defined namespace, which would seem odd.. This way, I guess the generic ITS functionality would need to stay at the extension level even though defined in the ITS Module.. We could also not care if the its: pointer or <its:rules> are in any way included in the XLIFF and just say that generic ITS processors need the external rules file with the <its:rules> as the root element, to read ITS data from an XLIFF 2 document. So we're back to defining an itsm: rules pointer attribute, that could live on <xliff> and be protected.. in the definition it would just say that it maps to and from the xlink:href The itsm:href could have a PR advisong how to expand into valid <its:rules> markup as extension on <file>. This would be a fallback in case anyone deleted the extended data that SHOULDN'T be deleted, yet still doesn't have an absolute protection. Cheers dF This might Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Mon, Aug 8, 2016 at 4:08 PM, David Filip <
david.filip@adaptcentre.ie > wrote: I noticed the pointer is just a generic href from the xlink namespace. So it would be cleaner to have the rules wrapper allowed on file, because the xliff extension point only allows attributes Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Mon, Aug 8, 2016 at 3:41 PM, Felix Sasaki <
felix@sasakiatcf.com > wrote: Hi David, Am 08.08.2016 um 16:38 schrieb David Filip <
david.filip@adaptcentre.ie >: Felix, looking at the example, it seems that we need to allow the rules element, even if we go for the external rules file, can you confirm? no - one can also say that it is up to the implementation. I am not sure what you mean by tool specific external rules referencing.. Would it be possible to have the rules pointer directly on <xliff> without an element wrapper? A pure ITS tool would not understand the pointer - the rules pointer is just an href attribute. and call it a tool specific way of rules referencing? Sure, tool specific is OK. Best, Felix Alternatively we could allow the rules element on the file extension point and we could enforce the rules pointer on every <file> element that contained any tsm data. It would be optional on any <file> elements, as it could serve generic ITS processors to parse ITS in native XLIFF features.. Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Mon, Aug 8, 2016 at 3:20 PM, Felix Sasaki <
felix@sasakiatcf.com > wrote: Hi David, Yves, I think Yves wrote about external rules as an ITS mechanism - not about rules in general, I think. Best, Felix Am 08.08.2016 um 15:59 schrieb David Filip <
david.filip@adaptcentre.ie >: Felix, Yves, The TC made the consensus a while ago (more than a year) that we do want the external rules file that would be universal for any XLIFF 2.1 Fredrik was the proponent of this idea, and everyone agreed with him at the end.. If you look at the proposed conformance statement and the whole ITSM spec, we do care about both conformance targets. the XLIFF Agent that knows about the ITS Module, but also at the generic ITS Processor that couldn't of course make any sense of an XLIFF file without the external rules file.. Felix's AI is to work on the external rules file and he already proposed solutions for a few categories (target pointer etc.) I was just asking what needs to be stated at the extension points to have the ability to reference the external rules file (once we have it). I think we didn't want to allow the ITS rules elements that would be needed to have the rules for generic ITS processors within each XLIFF Document. Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122 On Mon, Aug 8, 2016 at 1:58 PM, Felix Sasaki <
felix@sasakiatcf.com > wrote: Thanks, Yves, in that case forget what I wrote about external rules in XLIFF, that is then not relevant. - Felix Am 08.08.2016 um 14:55 schrieb Yves Savourel <
ysavourel@enlaso.com >: I don’t think it would make sense to have an external rules file in XLIFF: You would need to have an ITS processor to use it. The ITS module in XLIFF is meant to be used by XLIFF processors that know about that specific module, not about ITS. -ys From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ] On Behalf Of Felix Sasaki Sent: Monday, August 8, 2016 9:39 AM To: David Filip <
david.filip@adaptcentre.ie > Cc: XLIFF Main List <
xliff@lists.oasis-open.org > Subject: Re: [xliff] preparing csd01/csprd01 - Question where to allow ITSM elements and attributes Hi David, all, Am 05.08.2016 um 17:16 schrieb David Filip <
david.filip@adaptcentre.ie >: Hi all, I have been reviewing, which module elements and attributes are explicitly allowed on core. This seems in sync for ITSM elements. The top level ITSM elements that need allowed on core are <provenanceRecords> and <locQualityIssues> These currently list that they can be used on <unit> and they are also explicitly allowed on <unit> and nowhere else. ITSM attributes are explicitly allowed on <file>, <group>, <unit>, <mrk> and <sm>, which seems inline with other modules I believe there was a discussion why to allow the ITS containers only on unit. It think the main argument is to keep the standoff referencing within a unit, i.e. as close as possible to the inline spans that the annotations touch on. @Felix, another related issue. What about referencing the external rules file? Do you perhaps need the referencing attribute allowed on <xliff> for that? you can have a tool specific mechanism to reference external rules, or a rules element (see below) Other modules don't have attributes allowed on <xliff> but it could make sense to allow referencing the rules file from the root element for generic ITS processors.. Please let me know which attribute(s) need allowed where for that purpose. External rules can be linked like this
https://www.w3.org/TR/its20/#link-external-rules See example 17 which references external rules avail. in example 16. That solution needs an ITS rules element. Not sure if this is feasible for XLIFF. So one could stay with the tool specific mechanism to link to external rules. Best, Felix Anyways, I just wanted to confirm with the TC that there is no requirement to explicitly allow ITSM elements and attributes on other core elements.. Please let me know if there is use case that seems to indicate otherwise.. Please note that this doesn't touch on presence of ITSM in modules. The affected modules should be Translation Candidates, Change Tracking, Size and Length Restriction, and maybe Glossary.. This will be discussed separately. Cheers dF Dr. David Filip =========== OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer Spokes Research Fellow ADAPT Centre KDEG, Trinity College Dublin Mobile: +420-777-218-122