Re: [xliff] Minimum set of container elements for XLIFF 2.0

["Dr. David Filip" <David.Filip@ul.ie>]

Hi Yves, all,

Y27 seems good to me, and representing a hierarchical structure by flat attribute does not seem real simplification.

Group type seems important as well as ability to carry other metadata, and standard Xpath access.

Regarding B34, I think that it is a good idea to capture a new consensus on the set of container items. However, dependencies on other features should be made clear. Here the obvious dependency is on Y27 grouping that I fully support.

But things regarding skeleton are not clear enough and should be addressed first.

Looking briefly at the wiki, skeletons do not have a feature documented.

I think that skeleton should be addressed not only from the point of view of external|internal file but also in relation with ignorables and inline elements, including simple html preview..

And I do not think that we should as of now set any restrictions on proposing new features in section 2.

[I will elaborate on it separately.

We explicitly encouraged people to add features to section 2 and discuss them on mailing list first.

Uncontroversial features, do not need to be ever discussed online.. They can make it from wiki through electronic ballot directly into spec..]

Rgds

dF

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Tue, Mar 20, 2012 at 14:45, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi Rodolfo, Fredrik, Bryan, all,

> I really like the idea of simplifying XLIFF,
> especially in the core area.

+1

> Using attributes instead of group elements
> might be a step in that direction.

-1

> ...But to be able to represent the same hierarchy

> as we can with the 1.2 <group> element we would
> need two attributes on <unit> one "group-id" and
> one "parent-id" so we can build a tree of groups.
> We would also need to allow empty <units> to act
> as placeholders on pure group levels.

To me, that sound more complicated and less clean than having a <group> element.

In addition, it makes things like getting the 'bread crumbs' of the groups more difficult. It would also complicate how to access the structure using XPath-based utilities where there are natural ways to deal with such constructs.

Moreover, future modules and possibly extensions may need to have metadata attached to groups. Not having an element where to set those would mean replicating extra attributes in each <unit>.

I guess, what I'm saying is that the natural way to represent a hierarchy/structure in XLIFF would be a <group> element. Trying to 'simplify' this into a flat representation is bound to run into limitations and complications soon.

The thing that we probably need to discuss is whether representing hierarchy/structure should be a core feature or not, if it is then the most clean way to do it is with a <group>.

Cheers,
-yves

---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org