OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

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

Subject: RE: [xliff-inline] Attribute uniqueness

Hi Yves,

> In my opinion using the context seems more clear than forcing artificial names

I share this view.


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


To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org

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