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


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.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
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]