Re: [xliff-inline] Type of codes

[Arle Lommel <alommel@gala-global.org>]

Hi Yves,

Thanks for the response. To be clear, I wasn't suggesting getting rid of the functionality, but rather questioning whether it belongs at the element or the attribute level. I realize that any of the models could support the same functionality, so for me the question is which model comes the closest to the most common philosophy. For example if 95% of tools used only <ph> equivalents (I'm deliberately making an absurd argument, I know), then it would make sense to use only the <ph> element and add the additional functionality as optional attributes. If, on the other hand, we found that most tools use the more elaborate model with matching of start and end tags, that would argue (to me at least) that a <ph>-only model wouldn't be as good a fit. All that is independent of whether or not the simpler (in terms of elements) models can encapsulate the functionality of the more complex element sets.

I tend to like the idea of a <ph>-only model at the conceptual level because it captures a fundamental unity and it allows a match (at the element level) between all sorts of tool-specific ways of dealing with markup, thus capturing the similarities. On the other hand, if we use option 1 and a tool comes along that uses only <ph>, then its markup will not match the intention of the system, no matter what we do, because it would be unable to supply the elements we hope to see. Sure, tools could work around that, but if we push the information to attributes, it reveals the fundamental similarity. But I have to admit that this is really an aesthetic/theoretical preference, not one guided by practical concerns.

Best,

-Arle


On Dec 7, 2011, at 09:38 , Yves Savourel wrote:

> Hi Arle, all,
> 
>> But my thought is that there is no sense in making 
>> a solution that is more elaborate than what most 
>> tools actually do. Part of the answer to this 
>> question should be based on how do we support what 
>> the tools do and need.
> 
> Actually I don't think it matters: any of the proposed notation handles the same functionalities as far as using standalone or open/close codes. Only the syntax changes.
> 
> As for not providing an open/close functionality because some tools (and they are quite a few indeed) do not support those type of codes, I think it would cause an important lose of functionality.
> We would not be able to map 1.2 file to 2.0 anymore for example; QA tools which use open/close for validation would not be able to work very well; etc.
> 
> It would penalize quite a few tools, and I have no doubt that we would end up with custom extensions to fill the need :)
> 
> By the way: Bryan, Fredrik: thanks for posting your viewpoints too. It should help in the decision next week. Hopefully we'll get more posts on the topic.
> 
> 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
>