Re: [xliff-inline] Attribute uniqueness

[David Walters <waltersd@us.ibm.com>]

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