[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. Regards, Rodolfo -- From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Andrew Pimlott 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 extension. 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? Andrew 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... -yves |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]