OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi everyone, During the last inline SC meeting we talked about uniqueness of attribute names. Version 1.2 had, most of the time, attributes with different names when their value/semantics were different. For example we have <ph ctype> and <mrk mtype>, not <ph type> and <mrk type>. both represent 'type' information but with different descriptions and possible values. There was a consensus in the SC that it would be more in line with common practices to use simpler names even when they have different definitions and let the context (the element) mak the distinction. One example was HTML5 where 'options' has different values/definitions depending in which element is it. The SC felt that this needs to be decided soon by the TC, as even if names don't need to be finalized yet, this impact how the specification document is constructed. Cheers, -yves

I personally prefer using simpler names and leverage context to determine how it applies. From:         Yves Savourel <ysavourel@enlaso.com> To:         <xliff@lists.oasis-open.org> Date:         12/20/2011 06:52 AM Subject:         [xliff] SC feedback: Uniqueness of attribute names Sent by:         <xliff@lists.oasis-open.org> Hi everyone, During the last inline SC meeting we talked about uniqueness of attribute names. Version 1.2 had, most of the time, attributes with different names when their value/semantics were different. For example we have <ph ctype> and <mrk mtype>, not <ph type> and <mrk type>. both represent 'type' information but with different descriptions and possible values. There was a consensus in the SC that it would be more in line with common practices to use simpler names even when they have different definitions and let the context (the element) mak the distinction. One example was HTML5 where 'options' has different values/definitions depending in which element is it. The SC felt that this needs to be decided soon by the TC, as even if names don't need to be finalized yet, this impact how the specification document is constructed. Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org

I prefer using the same attribute name, like in HTML5. David Corporate Globalization Tool Development EMail:  waltersd@us.ibm.com           Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721 CHKPII:                     http://w3-03.ibm.com/globalization/page/2011 TM file formats:     http://w3-03.ibm.com/globalization/page/2083 TM markups:         http://w3-03.ibm.com/globalization/page/2071 Yves Savourel ---12/20/2011 05:52:15 AM---Hi everyone, During the last inline SC meeting we talked about uniqueness of attribute names. From: Yves Savourel <ysavourel@enlaso.com> To: <xliff@lists.oasis-open.org> Date: 12/20/2011 05:52 AM Subject: [xliff] SC feedback: Uniqueness of attribute names Sent by: <xliff@lists.oasis-open.org> Hi everyone, During the last inline SC meeting we talked about uniqueness of attribute names. Version 1.2 had, most of the time, attributes with different names when their value/semantics were different. For example we have <ph ctype> and <mrk mtype>, not <ph type> and <mrk type>. both represent 'type' information but with different descriptions and possible values. There was a consensus in the SC that it would be more in line with common practices to use simpler names even when they have different definitions and let the context (the element) mak the distinction. One example was HTML5 where 'options' has different values/definitions depending in which element is it. The SC felt that this needs to be decided soon by the TC, as even if names don't need to be finalized yet, this impact how the specification document is constructed. Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org