[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff-comment] csprd01-17: Structure and Structural Elements: <sm> <em> justification
Hi Yves,Although we have these MUST statements in the specification, they should be more prominently presented, for example, as you suggested, at the top of the specification, and possibly supported with an additional statement on interoperability between tools and user agents.
This then will make it totally clear that a MUST is a MUST for an efficient and effective deployment of XLIFF in the supply chain independent of the actually employed tool(s).
Thanks and cheers -- Jörg On June 18, 2013 at 11:12 (CEST), Yves Savourel wrote:
Thanks for the suggestions Jörg. I'll work on integrating them into the existing text (for example there is a full section on splitting annotation we can refer to).It is strongly recommended to use this mechanism instead of introducing custom attributes to accomplish a similar behavior with a series of <mrk> elements.I don't think we shoukd add the text above though. It is not just strongly recommend to not use custom mechanism: it is strictly forbidden. See http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/xliff-core-v2.0-csprd01.html#d0e7685 We can't keep saying for every single feature of the spec: "use this mechanism not a custom one". If it is not clear in the current document then it should be put in red capital letter at the top of the specification. It's valid for all XLIFF 2.0 constructs. Maybe in the http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/xliff-core-v2.0-csprd01.html#d0e497 section. But at the same time I'm not sure why this requirement should be stronger than another: a MUST is a MUST. Cheers, -ys