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] Permissons attributes


Hi Yves,

First on the set of hints. In my opinion the 3 described hints should be enough and I prefer the simple solution. But I do not oppose the more complicated solution with modifiable defaults.

On the non-clonable  codes my issue is that we need to make them work with segmentation. Since we decided to keep the <pc>/<g> tags we basically keep the issue described in the 1.2 standard. One way to solve this would be to define an un-ambiguous and reversible transform of the spanning inline tag into corresponding opening and closing pair of codes.

Let's assume the <pc> in this example represent a comment in a text bubble and as such cannot be duplicated.
"This is an example of <pc id="1" nid="cm1">the issue. Where a tag spans</pc> two sentences."

I propose that when we split this into two segments we lower the <pc> into a <sc>/<ec> pair. I put the intersegment whitespace in its own piece bellow but that is a different topic.
"This is an example of <sc id="sc1" nid="cm1" isolated="yes" orig-g-id="1">the issue.", " ", "Where a tag spans<ec id="ec1" nid="cm1" isolated="yes" orig-g-id="1"> two sentences."

Doing it along these lines should allow the segment to be split and at the same time allow the tool that created the Xliff file to back covert the file either by handling the split tag directly or by reversing the segmentation and tag splitting.

Regards,
Fredrik Estreen

-----Original Message-----
From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: den 10 februari 2012 14:10
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] Permissons attributes

Hi everyone,

To resume the discussion on the "editing hints".

(See http://lists.oasis-open.org/archives/xliff-inline/201111/msg00008.html for the initial reference)

The current trend was to think that having a single attribute per type of permission would be better than grouping them all in a single attribute.

So we would have something like this:

- canDelete="yes/no" default is "yes"
- canCopy="yes/no" default is "yes"
- canReorder="yes/no" default is "yes"

Is this still the consensus?


--- Defaults:

The default value is important as it would be nice to avoid having to set the attribute for each inline code. Does "yes" seems to be the right default?

An additional feature could be a <file>-level method to define the defaults. In that case, the attributes would have an extra value "default" and that would be their default value.

This would allow each filter to set the default at the file level and not have to set the attributes in the unit.

The drawback is that we would lose the self-containment of the unit. Just looking at the unit would not tell what the default is. We could also have either or both <group> and <unit> have a way to define the defaults I suppose.

Is trying to have a way to specify default better than keeping thing very basic?


--- Non-clonable codes

Fredrik: I think you "volunteered" to provide a short summary of the issue about non-clonable codes.

I believe this is the same problem as described after the first example of this 1.2 spec section: http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#Struct_Segmentation Is it correct?


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




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