[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Issues
Hi Yves, see answers / resolutions bellow. > -----Original Message----- > From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf > Of Yves Savourel > Sent: den 9 april 2013 14:39 > To: xliff@lists.oasis-open.org > Subject: [xliff] Issues > ... > -- The <cp> element has now attributes like size-info. I think this is wrong as > this element is just an escape mechanism (it would be like trying to assign a > restriction to "<") > > -- The attribute equiv-storage makes no sense on <cp> has this element is > not meant to store native code. > I removed the size restriction related attributes from <cp>, I agree that it is better to keep that element just for it single purpose of representing Unicode code points that are not allowed in XML. Restriction checking should happen on the string itself after <cp> is converted to a code point. ... > -- the PR "If the normalization attribute is set to "none", or is not present, it is > up to the processing agent to decide how to handle normalization." > contradict the description for "none" that says: "No normalization should be > done". Either it's up to the tool or "no normalization should be done", but it > can be both ways. I clarified the behavior here; to state that no additional normalization should be done. The content should be used as is. The thing is that there is nothing in the standard specifying how content should be normalized at creation or modification. So how the content looks will be determined by the agent(s) that change it before the restriction is checked. This will lead to some amount of implementation defined behavior if "none" is used. Regards, Fredrik Estreen
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]