[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] R37: Revised Validations Module proposal
I opt for no normalization on core – quote from my other mail today:
I actually think there should not be an attribute about normalization in the XLIFF core. In my opinion it makes sense to have it in length restrictions (because they refer to the storage format) and to a lesser extent in validation, but not in core. If you expect or need a specific normalization in your document, apply it.
Actually, even the normalization attributes in the size restriction module do not require the content be stored in that normalization
– which would also be difficult as the same content could have e.g. NFC for their storage size applied and NFD for general size restrictions.. it’s only used to know which calculation about sizes to apply.
So I think we both agree.
All, following the TC discussions last week, I believe the following needs to be answered.
Does the core need a default or even enforced storage normalization?
I believe the answer is no and we are OK with specifying a default for content comparison purposes that can be overridden in the validation module and in the size restriction module and nowhere else in the spec as it stands now AFAIK. In case these two introduce an explicit attribute that allows for the override, the default should be NFC in both cases, same as in 2.6.8.
If we decided that it is not enough to have normalization defaults for comparison purposes ONLY, we could introduce an optional normalization attribute in core that could live on any of the structural elements, from <file> down to <source> and <target>, there would be inheritance and the default/inherited would be assumed (MUST for processors) where nothing is specified/inherited.
The default could be either "none" or "NFC"
In case we go for the core attribute, I believe the default should be "none" for everything (including storage) except comparison purposes that would cover section 2.6.8 and both modules.
Please note that I am NOT actually proposing to have the core attribute, I am just trying to accelerate the discussion by charting all viable options.
Please indicate what option seems preferable to you, eventually if you see any other viable options..
Thanks and regards
Dr. David Filip
On Tue, Apr 2, 2013 at 3:59 PM, Estreen, Fredrik <Fredrik.Estreen@lionbridge.com> wrote:
Just back from vacation and catching up on email. Reading the current spec I think it could make sense to simply rely on section “2.6.8 Content Comparison” in the core specification for what (if any) normalization to apply for validation comparisons. It stipulates that NFC is used to compare the equality of content.