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: [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.

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.


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