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 … 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. 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.
Dr. David Filip OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer KDEG, Trinity College Dublin 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
Dr. David Filip OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer KDEG, Trinity College Dublin 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.
Dr. David Filip OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer KDEG, Trinity College Dublin 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 KDEG, Trinity College Dublin On Mon, Aug 8, 2016 at 3:41 PM, Felix Sasaki <felix@sasakiatcf.com> wrote: Hi David, 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.
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..
Dr. David Filip OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer KDEG, Trinity College Dublin 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. 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.
Dr. David Filip OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer KDEG, Trinity College Dublin 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 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. 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 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 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. 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. OASIS XLIFF OMOS TC Chair OASIS XLIFF TC Secretary, Editor, Liaison Officer KDEG, Trinity College Dublin
|