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

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?

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

http://lists.oasis-open.org/archives/xliff-inline/201111/msg00003.html

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

xliff message