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: Inline codes properties


Hi all,

To get the discussion going on the topic of addition/deletion of inline codes. Here are a few thoughts:

=== Indicators:

- we need a way to indicate if a code can be duplicated

- we need a way to indicate if a code can be deleted

- do we need a flag indicating if a code can be moved out of order?


=== Additional codes:

- we need a way to represent a new code (i.e. created after the initial extraction)

- we need a way to represent a duplicated code (i.e. created from a cloneable existing code).


A first option for the indicators:

-- An attribute (e.g. 'perm') with a numeric value that is the ORed result of individual values.

- can be duplicated = 0x1
- can be deleted = 0x2
- can be duplicated and deleted = (0x1 | 0x2) = 0x3

For example: <code id='1' perm="3"/> 


-- Another option would be to use a set of letters indicating the permissions:

- can be duplicated (cloned) = "c"
- can be deleted = "d"
- can be duplicated and deleted = "cd" or "dc"

It is slightly easier to implement. For example: <code id='1' perm="cd"/>

Or use a list of values: perm="delete;clone"

In all cases, the default would be that an inline element can be cloned and deleted. Like in 1.2.

The attribute would be available for all elements that represent code for native data, regardless of the notation. Note that in 1.2 the clone attribute can go only on <g> and <x>, not <bpt>, etc.

Any thoughts?


=== Representation of added codes:

--- new code created after extraction.

Those are codes provided by a tool during, for example, edit. For instance to bold a word not bolded in the source language, etc.
They are no correspondence in original document and not in the skeleton.

- what id should they have? (assuming is a required attribute)

- should providing the native data mandatory? Or can just providing the type (e.g. bold) and let the tool add the code if it can is also something we want to provide?


--- Duplicated code.

They should point to the same native data as the code it has been duplicated from.

- what id should they have? (assuming is a required attribute)

- should they just have the same id as the original code? And we assume the tool merge the same native code.


-ys




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