Hi David, all, Am 28.07.2017 14:57 schrieb "David Filip" <
david.filip@adaptcentre.ie >: Felix, I updated the rule for Terminology <!-- Rules for Terminology --> <its:termRule selector="//xlf:*[@type='term' or @type='its:term-no']" termInfoRefPointer="@ref" termInfoPointer="@value"/> I wonder that this could be made three more explicit rules likes this <its:termRule selector="//xlf:*[@type='term' or @type='its:term-no'][@ref]" termInfoRefPointer="@ref"/> <its:termRule selector="//xlf:*[@type='term' or @type='its:term-no'][@value]" termInfoPointer="@value"/> <its:termRule selector="//xlf:*[@type='term' or @type='its:term-no']"/> I assume the above one rule does the same, I am just not exactly sure if this can be done this way.. because there will be never both of them, so it might be more efficient for processing to know which of them to expect if any... The rules look OK but the order should be different. The last rule should be the first rule since its xpath _expression_ is most general. In the current order, this prevents the two specific rules from matching, because in ITS always the last rule wins. Cheers, Felix I guess I am now done with editing the ITS Rules except that the one ITS Rule could be replaced with the three based on your feedback. So I guess all the rules should be tested now. I tested the Localization Note Rules as I was developing them, but had to manually rewrite them with xlf: so running more tests is advisable. Also I will try and give a stab to the use case 10 where unit level notes don't have appliesTo 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 Thu, Jul 27, 2017 at 5:38 PM, David Filip <
david.filip@adaptcentre.ie > wrote: Hi Felix, I think I have it basically cracked on one online Xpath validator. It is w/o the xlf prefix, as it wouldn't work on the validator.. This selects all file level notes of the highest priority that apply to all content //file/notes/note[not(@applies To) and not(@priority) or @priority=1] and with this u descend back to the relevant source //file/notes/note[not(@applies To) and not(@priority) or @priority=1]/../..//segment/so urce or target //file/notes/note[not(@applies To) and not(@priority) or @priority=1]/../..//segment/ta rget so the final set of nodes should be //file/notes/note[not(@applies To) and not(@priority) or @priority=1]/../..//source //file/notes/note[not(@applies To) and not(@priority) or @priority=1]/../..//target and the locNotePointer should be simply the first common part of the expressions //file/notes/note[not(@applies To) and not(@priority) or @priority=1] or just the text content of it? All else is just variations of the above using group and unit instead of file and the other priorities (2-10) please note the usage of //segment/target //segment/source when descending otherwise it would also select xlf source and targets wrapped in mtc.. I guess, I can update the rules and you and Yves can test them? The selector for the Loc Note in value of a comment annotation works fine It should just become //mrk [@type='comment' and @value] //sm [@type='comment' and @value] or we could simplz go back to //xlf:* [@type='comment' and @value] as nothing in xlf can fullfill the "and" condition But I wonder if it's indeed enough to use @value as the pointer? I guess it should be something like //segment/source//mrk[@value] //segment/target//mrk[@value] //segment/source//sm[@value] //segment/target//sm[@value] or again //segment/source//xlf:*[@value ] //segment/target//xlf:*[@value ] I am not quite sure what is the relationship between the selector and pointer and if the pointer can get the necessary context from the selector? BTW I noticed two other possible issue <!-- Rules for Terminology --> <its:termRule selector="//xlf:mrk[@type='ter m' and @ref]" termInfoRefPointer="@ref"/> This doesn't seem to select non-terms I think I have asked about that before, but I don't remember the reason not to select the non-terms. also the ref is optional on the term annotation, so the above seems too strong Similarly <!-- Rules for Domain --> <its:domainRule selector="//xlf:mrk[@type='its :generic' and (@itsm:domains)]" domainPointer="@itsm:domains"/ > the type="its:generic" is optional so the 'and' condition is too strong and also domain can be on other elements, not just mrk. So this should do the trick? <its:domainRule selector="//xlf:*[@itsm:domain s]" domainPointer="@itsm:domains"/ > 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 Thu, Jul 27, 2017 at 2:14 PM, Felix Sasaki <
felix@sasakiatcf.com > wrote: Thanks, David. If you have one example that covers this description from Yves " For example, we have rules with selectors like this: selector="//xlf:unit[@appliesT o='source']//xlf:source[ancest or::xlf:unit[@appliesTo='sourc e']/xlf:notes/xlf:note[@priori ty=1]]" But the appliesTo predicate should be on the note, not on the unit. So it should be something like: selector="//xlf:source[../../x lf:unit/xlf:notes/xlf:note[app liesTo="source" and @priority=1]]" Furthermore the priority condition is more complete: priority==1 or no priority (because 1 is the default) means an alert, while priority>=2 means a description. It seems to me the Localization notes rules need an overhaul and a test file with one example per case. " I can use that to move on. - Felix 2017-07-27 13:24 GMT+02:00 David Filip <
david.filip@adaptcentre.ie > : Hi all, I created and committed a test file that can be used to validate all the Localization Note rules
http://tools.oasis-open.org/ve rsion-control/browse/wsvn/xlif f/trunk/xliff-21/test-suite/mo dules/valid/withNotes_complex_ for_ITS_Processors.xlf I will try and debug the selectors based on that 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 Sun, Jul 23, 2017 at 7:53 AM, Yves Savourel <
ysavourel@enlaso.com > wrote: Yes, Felix is waiting for me. And I’m afraid I had zero time so far. -ys From: Felix Sasaki [mailto:
felix@sasakiatcf.com ] Sent: Saturday, July 22, 2017 7:32 AM To: David Filip <
david.filip@adaptcentre.ie > Cc: Yves Savourel <
ysavourel@enlaso.com >; Felix Sasaki <
felix@sasakiatcf.com >; XLIFF Main List <
xliff@lists.oasis-open.org > Subject: Re: [xliff] ITS rules syntax Hi David, in my previous mail I had some questions and Yves did not yet have time to look into this, it seems. I need that input to move forward. Best, Felix 2017-07-21 13:06 GMT+02:00 David Filip <
david.filip@adaptcentre.ie >: Yves, Felix, please help me understand what's the status of the faulty xpath expressions. Has all been fixed /tested or is anything pending at the moment? This is the critical issue AFAIK preparing for the 1st August meeting, so let's wrap it up Cheers and thanks 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 Wed, Jun 28, 2017 at 2:56 PM, Yves Savourel <
ysavourel@enlaso.com > wrote: Hi Felix, Thanks for the updated rules. I’ll try to reformulate things as soon as I some time. -yves From:
xliff@lists.oasis-open.org [mailto:
xliff@lists.oasis-open .org ] On Behalf Of Felix Sasaki Sent: Tuesday, June 27, 2017 10:07 PM To: Yves Savourel <
ysavourel@enlaso.com > Cc: David Filip <
david.filip@adaptcentre.ie >; XLIFF Main List <
xliff@lists.oasis-open.org > Subject: Re: [xliff] ITS rules syntax Hi Yves, David, all, I tried to implement the changes related to Localization Note asked for in this thread, except the changes Yves described in this mail. Yves, could you reformulate one rule completely, with the pointer attribute included? I will then do the other changes that involve @appliesTo based on that example. Thanks a lot in advance. I agree that a test file would be very useful, but won't have the bandwidth at the moment to create one. Cheers, Felix 2017-06-23 13:14 GMT+02:00 Yves Savourel <
ysavourel@enlaso.com >: There are other issues: For example, we have rules with selectors like this: selector="//xlf:unit[@appliesT o='source']//xlf:source[ancest or::xlf:unit[@appliesTo='sourc e']/xlf:notes/xlf:note[@priori ty=1]]" But the appliesTo predicate should be on the note, not on the unit. So it should be something like: selector="//xlf:source[../../x lf:unit/xlf:notes/xlf:note[app liesTo="source" and @priority=1]]" Furthermore the priority condition is more complete: priority==1 or no priority (because 1 is the default) means an alert, while priority>=2 means a description. It seems to me the Localization notes rules need an overhaul and a test file with one example per case. Cheers, -yves From:
xliff@lists.oasis-open.org [mailto:
xliff@lists.oasis-open .org ] On Behalf Of Yves Savourel Sent: Friday, June 23, 2017 12:19 PM To: 'David Filip' <
david.filip@adaptcentre.ie > Cc: 'XLIFF Main List' <
xliff@lists.oasis-open.org > Subject: RE: [xliff] ITS rules syntax We are also missing the case of the comment annotation using a @ref instead of a @value. Something like: <its:locNoteRule selector="//xlf:mrk[@type='com ment' and @ref]" locNoteRefPointer="@ref" locNoteType="alert"/> But this needs to be tweaked for the locNoteType: ‘alert’ if the note has a priority of 1 or none, ‘description’ otherwise. I’m not sure how you would express this though as the priority value is in the referenced <note>. Maybe Felix or Soroush have ideas? -yve From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open .org ] On Behalf Of Yves Savourel Sent: Friday, June 23, 2017 12:03 PM To: 'David Filip' <
david.filip@adaptcentre.ie > Cc: 'XLIFF Main List' <
xliff@lists.oasis-open.org > Subject: RE: [xliff] ITS rules syntax There is at least one other error in a rule: <its:locNoteRule selector="//xlf:*[@ annotation = 'comment' and @value]" locNotePointer="@value" locNoteType="description"/> Should be: <its:locNoteRule selector="//xlf:*[@ type ='comme nt' and @value]" locNotePointer="@value" locNoteType="description"/> Or probably even: <its:locNoteRule selector="//xlf:mrk[@type='com ment' and @value]" locNotePointer="@value" locNoteType="description"/> Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ® From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open .org ] On Behalf Of Yves Savourel Sent: Friday, June 23, 2017 11:33 AM To: 'David Filip' <
david.filip@adaptcentre.ie > Cc: 'XLIFF Main List' <
xliff@lists.oasis-open.org > Subject: RE: [xliff] ITS rules syntax I’ve started to look at why our okapi ITS processor was getting a null pointer. It looks like it’s because the rules are have an attribute localizationNotePointer instead of locNotePointer. So one more typo to correct. I’m not sure the expressions work though: I get no error, but no notes associated with nodes either (so far). Yves Savourel Localization Solutions Architect t: 303.951.4523 f: 303.516.1701 ENLASO ® From: David Filip [ mailto:david.filip@adaptcentr e.ie ] Sent: Wednesday, June 21, 2017 6:43 PM To: Yves Savourel <
ysavourel@enlaso.com > Cc: XLIFF Main List <
xliff@lists.oasis-open.org > Subject: Re: [xliff] ITS rules syntax Yves, Soroush, Felix, all Are the rules working now? Was it an easy syntax fix attributable to a typo or export error, but no actual ambiguity as to where on the XLIFF tree the rules apply? Please let us know, it seems to me that the cs01 fate hinges on the answers to the above questions.. 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, Jun 19, 2017 at 12:07 AM, Yves Savourel <
ysavourel@enlaso.com > wrote: Thanks Soroush. I get some null pointer now, but that may be a bug in our ITS engine implementation. Somehow the selector return null. I’ll have to go debug that… -ys From: Soroush.Saadatfar [mailto:
Soroush.Saadatfar@ul.i e ] Sent: Sunday, June 18, 2017 4:02 PM To: Yves Savourel <
ysavourel@enlaso.com > Cc: XLIFF Main List <
xliff@lists.oasis-open.org > Subject: Re: [xliff] ITS rules syntax Dear Yves, I believe it was supposed to be //xlf:file // xlf:source… //xlf:file[not(@appliesTo)] // x lf:target... to select all sources and targets of a file respectively. Soroush. On Jun 18, 2017, at 5:10 PM, Yves Savourel <
ysavourel@enlaso.com > wrote: Thanks Soroush & Felix. Did you really mean “//:” by “/”? (seems to get errors too) Or “//: : ” by “/” (seems to be pass, syntactically). Thanks -yves From: Felix Sasaki [ mailto:
felix@sasakiatcf.com ] Sent: Sunday, June 18, 2017 1:33 PM To: Yves Savourel <
ysavourel@enlaso.com > Cc: XLIFF Main List <
xliff@lists.oasis-open.org > Subject: Re: [xliff] ITS rules syntax Hi Yves, all, you are right, this is not the correct syntax, probably due to export from Oxygen editor? Anyway replacing //: by / should help. - Felix 2017-06-18 18:42 GMT+02:00 Yves Savourel <
ysavourel@enlaso.com >: Hi all, Are we sure the ITS rules in its.sch (especially the locNoteRule ones) are correct? I’m getting syntax errors like “A location step was expected following the '/' or '//' token.” When trying to process them. I’m certainly no XPath expert, but the “//::” parts look odd. For example a rule like: //xlf:file//::xlf:source[ances tor::xlf:file[not(@appliesTo)] /xlf:notes/xlf:note[@priority= 1]] //xlf:file[not(@appliesTo)]//: :xlf:target[ancestor::xlf:file [not(@appliesTo)]/xlf:notes/xl f:note[@priority=1]] Does not pass any online XPath evaluators/validators I’ve tried. Thoughts? -yves