XLIFF Inline Markup SC

Hi everyone, Working with Rodolfo on the draft specification I realize that his plan is to have, like in version 1.2, unique attribute names. For example (in 1.2) a 'type' attribute is 'ctype' when in <bpt> and 'mtype' when in <mrk>, or an identifier is 'id' in <trans-unit> and 'mid' in <mrk> (although it's 'id' in <bpt>). I think the idea is to have one attribute name per different semantic usage, so we can have a list of attribute and each one has a single definition and list of values. It's actually not quite respected in 1.2 (e.g. <trans-unit> and <bpt> use both 'id' despite the fact they have different scopes). The opposite view would be to allow the context of where the attribute lives to make the distinction. For example a 'type' in <ph> and a 'type' in <mrk> would be named both 'type' but have local definitions pertaining to their respective elements. In my opinion using the context seems more clear than forcing artificial names. That's what format like HTML do: the 'value' attribute in HTML5 for example has 5 different semantics and is used in 7 elements, but it's called 'value' everywhere. But I understand the other viewpoint too, different names makes the documentation easier to structure, and may help some users. Note that both solutions can be validated correctly in the schema. Note also that the question is not just for attribute of inline elements, but also structural element (<unit id>, <segment id>, etc. or <unit unitId>, <segment segmentId>, etc.): QUESTION: So, what you think should be the way to go? Note that this would have a consequence on our attribute naming for the start/end cases. In our inline codes we have cases like 'subFlows' that is currently named 'subFlows' in <sc> and <ec> and <ph>, but has to be named 'subFlowsStart' and 'subFlowsEnd' in <pc>. If we use unique attribute names 'subFlows' can be used only for <ph>, not for <sc> and <ec>, which should then use respectively 'subFlowsStart' and 'subFlowsEnd'. The same goes for 'disp', 'equiv' and any attributes with sart/end values. We started to discuss this last month, but the discussion branched to "<pc> vs <sc>/<ec>", so we never had a conclusion on this. Cheers, -yves

Hi Yves, > In my opinion using the context seems more clear than forcing artificial names I share this view. Cheers, Christian
Original Message----- From: xliff-inline@lists.oasis-open.org [ mailto:xliff-inline@lists.oasis-open.org ] On Behalf Of Yves Savourel Sent: Mittwoch, 7. Dezember 2011 13:50 To: xliff-inline@lists.oasis-open.org Subject: [xliff-inline] Attribute uniqueness Hi everyone, Working with Rodolfo on the draft specification I realize that his plan is to have, like in version 1.2, unique attribute names. For example (in 1.2) a 'type' attribute is 'ctype' when in <bpt> and 'mtype' when in <mrk>, or an identifier is 'id' in <trans-unit> and 'mid' in <mrk> (although it's 'id' in <bpt>). I think the idea is to have one attribute name per different semantic usage, so we can have a list of attribute and each one has a single definition and list of values. It's actually not quite respected in 1.2 (e.g. <trans-unit> and <bpt> use both 'id' despite the fact they have different scopes). The opposite view would be to allow the context of where the attribute lives to make the distinction. For example a 'type' in <ph> and a 'type' in <mrk> would be named both 'type' but have local definitions pertaining to their respective elements. In my opinion using the context seems more clear than forcing artificial names. That's what format like HTML do: the 'value' attribute in HTML5 for example has 5 different semantics and is used in 7 elements, but it's called 'value' everywhere. But I understand the other viewpoint too, different names makes the documentation easier to structure, and may help some users. Note that both solutions can be validated correctly in the schema. Note also that the question is not just for attribute of inline elements, but also structural element (<unit id>, <segment id>, etc. or <unit unitId>, <segment segmentId>, etc.): QUESTION: So, what you think should be the way to go? Note that this would have a consequence on our attribute naming for the start/end cases. In our inline codes we have cases like 'subFlows' that is currently named 'subFlows' in <sc> and <ec> and <ph>, but has to be named 'subFlowsStart' and 'subFlowsEnd' in <pc>. If we use unique attribute names 'subFlows' can be used only for <ph>, not for <sc> and <ec>, which should then use respectively 'subFlowsStart' and 'subFlowsEnd'. The same goes for 'disp', 'equiv' and any attributes with sart/end values. We started to discuss this last month, but the discussion branched to "<pc> vs <sc>/<ec>", so we never had a conclusion on this. Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org

Using the context seems more consistent with other standards. 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/07/2011 06:50:29 AM---Hi everyone, Working with Rodolfo on the draft specification I realize that his plan is to have, lik From: Yves Savourel <ysavourel@enlaso.com> To: <xliff-inline@lists.oasis-open.org> Date: 12/07/2011 06:50 AM Subject: [xliff-inline] Attribute uniqueness Sent by: <xliff-inline@lists.oasis-open.org> Hi everyone, Working with Rodolfo on the draft specification I realize that his plan is to have, like in version 1.2, unique attribute names. For example (in 1.2) a 'type' attribute is 'ctype' when in <bpt> and 'mtype' when in <mrk>, or an identifier is 'id' in <trans-unit> and 'mid' in <mrk> (although it's 'id' in <bpt>). I think the idea is to have one attribute name per different semantic usage, so we can have a list of attribute and each one has a single definition and list of values. It's actually not quite respected in 1.2 (e.g. <trans-unit> and <bpt> use both 'id' despite the fact they have different scopes). The opposite view would be to allow the context of where the attribute lives to make the distinction. For example a 'type' in <ph> and a 'type' in <mrk> would be named both 'type' but have local definitions pertaining to their respective elements. In my opinion using the context seems more clear than forcing artificial names. That's what format like HTML do: the 'value' attribute in HTML5 for example has 5 different semantics and is used in 7 elements, but it's called 'value' everywhere. But I understand the other viewpoint too, different names makes the documentation easier to structure, and may help some users. Note that both solutions can be validated correctly in the schema. Note also that the question is not just for attribute of inline elements, but also structural element (<unit id>, <segment id>, etc. or <unit unitId>, <segment segmentId>, etc.): QUESTION: So, what you think should be the way to go? Note that this would have a consequence on our attribute naming for the start/end cases. In our inline codes we have cases like 'subFlows' that is currently named 'subFlows' in <sc> and <ec> and <ph>, but has to be named 'subFlowsStart' and 'subFlowsEnd' in <pc>. If we use unique attribute names 'subFlows' can be used only for <ph>, not for <sc> and <ec>, which should then use respectively 'subFlowsStart' and 'subFlowsEnd'. The same goes for 'disp', 'equiv' and any attributes with sart/end values. We started to discuss this last month, but the discussion branched to "<pc> vs <sc>/<ec>", so we never had a conclusion on this. Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org