OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

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


Subject: RE: Resolution of your public review comments: 030, 031, 033, 034


Hi Bryan,

Regading point 033 below, I've just read the Validation module as published with datestamp August 20, 2013 and I seem to still have a couple of doubts regarding the use cases of the validation module:

1. As described in the spec, attributes like isPresent, isNotPresent, startWith, and endsWith take substring.  Are these substrings case-sensitive? If so, how can they be made case-insenstive? If not, how can they be made case-sensitive?

2. Examples of usage in the spec for isPresent show these substrings matching whole words, but it is a coincidence.  I understand by the spec that it you have <rule isPresent="iphone"> and <target> contains "triphone", you pass the validation rule for that target segment.  Is it correct to understand that in spite of examples showing usage with whole words, to check the isPresent validation one must not consider it a whole word.   

3. I am under the impression that regular expression-like rules might be needed in several production scenarios. However, it is not fully clear to me how one can use custom rules to extend the validation rules syntax with, for example, one supporting a RegEx-like grammar.  For custom rules, in the list of constraints, the spec reads "a custom rule defined by attributes from any namespace is REQUIRED in any one <rule> element.".  Could you please provide an example of how one could define custom rules with an alternative (RegEx-like) grammar in a way that is still compliant with the validation module?

Regards,
Josep. 

-----Original Message-----
From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com] 
Sent: viernes, 30 de agosto de 2013 21:54
To: Chase Tingley
Cc: xliff-comment@lists.oasis-open.org
Subject: [xliff-comment] Resolution of your public review comments: 030, 031, 033, 034

Chase

I've been scanning our comment list to be sure that we've closed the loop on all of the very useful comments we received from you. I can see that members of the TC have been in fruitful discussion about your comments, questions, and suggestions. But there are a few of your items we've resolved, but I'm not sure that we've communicated our resolution to you. So just to be sure we close on all of the issues you've raised regarding our XLIFF 2.0 first public review, I want to take a moment to address those for which I could not find what I would consider a complete communication back to you. Please forgive me if any of this is redundant (in the case where you may have been replied to - but I just didn't see it).

I will use the comment numbers we've documented in our wiki tracker https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker

030: You had three comments on the basic structure. part 1, we clarified the <file> and <group> granularity (http://markmail.org/thread/7eyc7565iqhhv3mu) part 2, confusion about <ignorable>, Ryan expressed the same opinion, and the TC resolved it with a better definition (https://lists.oasis-open.org/archives/xliff-comment/201307/msg00016.html), part 3, the use of @fs on notes, I already communicated the TC's consensus on this (https://lists.oasis-open.org/archives/xliff-comment/201308/msg00010.html)


031: You had three questions around the SLR module. We spent a good deal of time looking and came to consensus about naming and improved processing requirements (https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201308/msg00090.html)

033: You raised several issues around the Validation module that the TC spent a lot of time grappling with. In the end we improved this module and came to consensus about how to resolve your issues (and the similar issues, 057 and 061). They are summarized by Ryan and company (https://lists.oasis-open.org/archives/xliff/201307/msg00099.html).

034: You asked questions about the Matches module. This lead to several rounds of debate in the TC. But we ultimately agreed to make id on matches compulsory, clarify on suitability attributes, introduce pointing from inline annotations, and remove mentions of <segment> (as result of the resegmentation changes), a high level summary is here (http://markmail.org/thread/2mqkks4n6aftodjm).

I know this is a bit scattered. I hope it communicates the direction the TC feels is best, based on your very much appreciated inputs.

Thanks again for taking the time to help us to put out the best XLIFF 2.0 we can. Please continue to call on us with any questions, concerns, or feedback.

Thanks,

Bryan


--
This publicly archived list offers a means to provide input to the OASIS XML Localisation Interchange File Format (XLIFF) TC.

In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.

Subscribe: xliff-comment-subscribe@lists.oasis-open.org
Unsubscribe: xliff-comment-unsubscribe@lists.oasis-open.org
List help: xliff-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/xliff-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff
Join OASIS: http://www.oasis-open.org/join/



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