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


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

Subject: RE: [xliff] Re: Hint representation

Hi Andrew,


At this stage the name “hint” really doesn’t matter. It may be misleading but we don’t care very much at this time. All we need is to agree on functionality, later we will have to adapt element and attribute names to be as much backwards-compatible as possible without creating confusion with new concepts or new functionality.


Of those 2 options mentioned by Yves, I prefer the second. It’s easier to check if a letter is present in an attribute value than deciphering OR’ed values.


Regarding default values, I would not allow all operations by default. I would expect all inline elements from source to be present in the corresponding target and to be in the same order whenever possible. Deleting, replicating or reordering should be exceptionally used, not the default enabled action.




Rodolfo M. Raya       rmraya@maxprograms.com


From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Andrew Pimlott
Sent: Thursday, December 15, 2011 8:04 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] Re: Hint representation


Following up on Yves's message and the discussion on the last call about

"hints" for inline codes (canBeDeleted, canBeReplicated, etc).


First, I said on the call that I would prefer a separate attribute for each

boolean hint.  I would probably do this if I were designing just for myself,

since I don't mind verbosity, but this isn't a strong opinion.  I care less

about literal representation than structure, and the structure is the same

either way.


I would note that the flag idea sounds like it would be hard to validate

with XML Schema.  You would want to say that the value must contain at most

one of each from a set of characters.  Can you do this?


Second, everyone seemed to agree on the call that the set of hints would

probably not need to be extended.  I've been pondering this, and I don't

believe it's true.  The discussion about overlapping markup made me realize

there are other ways you might want to manipulate codes that may or may not

be allowed.  For example, is it allowed to make previously non-overlapping

codes overlap?


I think it's worth considering lots of examples and working out exactly what

the hints mean before thinking about representation.  That might help us

decide if we have an exhaustive set, or if we need to consider future



Finally, I think calling them "hints" is misleading.  If respecting the

"hints" will be part of the processing requirements, they're not just hints,

are they?




On Thu, Dec 15, 2011 at 1:25 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

(Forged message from Yves for me to reply to)


Hi everyone,


We have all an action item from the last meeting: "All to think about representation for hints."


The hints can be:


1: a code can be deleted

2: a code can be replicated

3: a code can be moved out of its original order

(and possibly 4: a code can be moved outside its original parent span)



Here are two possible notations:


1) hint='value' where value is an integer with ORed flags


canBeDelete = 0x01

canBeReplicated = 0x02

canBeReordered = 0x04

(canBeReparented = 0x08)


hint='3' means the code can be both delete and replicated, but it cannot be re-ordered.

hint='0' means the code cannot be delete, replicated or moved or re-parented.

hint='15' means the code can have all operations done.



2) hint='value' where value is a string with symbolic characters acting as flag being set.


canBeDelete = 'd'

canBeReplicated = 'r'

canBeReordered = 'o'

(canBeReparented = 'p')


hint='dr' means the code can be both delete and replicated, but it cannot be re-ordered.

hint='' means the code cannot be delete, replicated or moved or re-parented.

hint='drop' means the code can have all operations done.



In both case it seems the default could be to allow all operations.


I'm not very warm on having an attribute for each hint because it could very quickly get us unnecessarily cluttered and large codes.


Looking forward to other ideas...




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