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] Minimum set of container elements for XLIFF 2.0

Hi Rodolfo, Fredrik, Bryan, all,

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


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


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


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