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: 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.
 
 
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
 
 
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
 
 
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/itsan 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
 
 
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
 
 
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
 
 
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
 
 
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.orgOn 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
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




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