Re: [xliff] Re csprd01 comment 006 was: Fwd: what was our position on core, modules, extensions order in XLIFF 2.0?

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

Hi everyone,

following up on the discussion in today's meeting I am making this call for dissent. Please respond by the end of this week (Friday your local COB) if you wish to reject or amend the below proposal.

Thanks and regards

dF

Background:

People generally did not care/were OK/saw benefits with enforcing order, we also agreed that it is better to have consistent order at all levels.

We also so far did not hear dissent against notes at structural levels above unit.

Proposal:

So the proposal is to keep core order (with propagating notes to group and file), have modules in specified order and custom namespace based elements always last (we obviously cannot foresee the order of custom extended elements). The modules and extension order should be consistent on all levels.

The resulting tree should look like this:

<xliff> 1

|

+---<file> +

     |

     +---<skeleton> ?

     |

     +---<notes> ?

     |   |                

     |   +---<note> +

     |

     +---<mda:metadata> ?

     |

     +---<res:resourceData> *

     |

     +---<slr:profile> ?        

     |

     +---<val:validation> ?        

     |

     +--- At least one of (<group>* or <unit>*)

     |

     +---<group> *

     |   |

     |   +--- At least one of (<group>* or <unit>*)

     |   |

     |   +---<notes> ?

     |   |   |                

     |   |   +---<note> +

     |   |

     |   +---<mda:metadata> ?

     |   |

     |   +---<val:validation> ?

     |   |

     |   +---<any> *

     |

     +---<unit> *

     |   |                

     |   +---<segment> +

     |   |   |                

     |   |   +---<source> 1

     |   |   |                

     |   |   +---<target> ?

     |   |

     |   +---<ignorable> *

     |   |   |                

     |   |   +---<source> 1

     |   |   |                

     |   |   +---<target> ?

     |   |                

     |   +---<notes> ?

     |   |   |                

     |   |   +---<note> +

     |   |                

     |   +---<originalData> ?

     |   |       |                

     |   |       +---<data> +

     |   |

     |   +---<mtc:matches> ?

     |   |

     |   +---<gls:glossary> ?

     |   |

     |   +---<mda:metadata> ?

     |   |

     |   +---<ctr:changeTrack> ?

     |   |

     |   +---<val:validation> ?

     |   |

     |   +---<any> *

     |

     +---<any> *

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 Mon, Jul 1, 2013 at 3:52 PM, Dr. David Filip <David.Filip@ul.ie> wrote:

Thanks Ryan, i agree with removing the notes as well, it will be easier than making processing requirements for them

And I also agree that notes can appear on all structural levels above segment.

Cheers

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 Fri, Jun 28, 2013 at 9:04 PM, Ryan King <ryanki@microsoft.com> wrote:

Thanks David, I still think that according to our F2F discussion in London, <notes> needs to be removed from <segment> level as well.

 

Just as an aside, is there any reason why <notes> doesn’t appear on <group> or <file> level? Isn’t it conceivable that you may want a comment that applies to all <units> in a particular <group> or <file>? Otherwise, I think people may use <mda:metadata> to carry this information? Do we want that?

 

From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Thursday, June 27, 2013 1:42 PM
To: Ryan King
Cc: Dr. David Filip; xliff@lists.oasis-open.org; Estreen, Fredrik; Sean Mooney
Subject: Re: [xliff] Re csprd01 comment 006 was: Fwd: what was our position on core, modules, extensions order in XLIFF 2.0?

 

Ryan, thanks for catching those omissions.., more details inline below..

 

The resulting proposed tree here:

 

 

 

 

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 Thu, Jun 27, 2013 at 8:18 PM, Ryan King <ryanki@microsoft.com> wrote:

Hi David, Fredrik, all,

 

Just curious, but what is the rationale for enforcing an order of elements (sorry if I missed it in a discussion somewhere)?

 

IMHO there was no discussion, just that there traditionally was an enforced order of elements.

Yves said in his comment that he does not see a reason to enforce order and I did not see (or missed) discussions pertaining to this comment.

IMHO (supported by the view of our developers) having a standard order may make processing easier (and I do not mean processing as an internal format, as this is out of scope and I do not want to discuss that again) than in case all can be anywhere.

 

IMHO there are three general options, 

 

1) say that order is always arbitrary [not sure how developers would like this, listing this just to be logically complete]

2) have always core > modules > extesnions and have modules order arbitrary

3) enforce canonical order - consistent on all levels

 

The detailed proposal below is for option 3

we currently have option 

4) i.e. canonical order with inconsistent order on different levels, which seems suboptimal

 

Regarding the structure you have below, David:

1.      I believe the ballot passed to remove <gls:glossary> from <file>.

Good catch, Sean was not aware of this and I forgot to remove it 

2.       [Removed modules and extensions from segment, anticipating the resegmentation solution] I believe <notes> needs to be removed from <segment> as well.

This also depends on the resegmentation discussion outcome. I beleieve that notes as a core element does not need to be necessarily removed, or at least it does not go automatically with the decision to dump modules and extensions

3.      Do we want to leave <mda:metadata> on <ignorable>? Or do we want to have mechanism for an <mda:metadata> on the <unit> to reference <ignorable> to be consistent with other types of module referencing that we need to introduce for <segment>?

You are right, we should be consistent here 

 

Ryan

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: Thursday, June 27, 2013 11:10 AM
To: xliff@lists.oasis-open.org; Estreen, Fredrik; Sean Mooney
Subject: [xliff] Re csprd01 comment 006 was: Fwd: what was our position on core, modules, extensions order in XLIFF 2.0?

 

Hi Fredrik, all,

 

regarding the order of core, module, and extension elements I propose the following solution by Sean Mooney, who will join the TC on behalf of LRC early next month

 

If an order is to be enforced it would be preferable if non core element came either  first or last.

currently both group and unit allow any element to be placed after all core elements but not file, which allows any element to be placed after the modules but before group or unit.

my suggestion for the ordering would be to match it up with the ordering within group and unit where
xliff core elements appear first,
followed by the core modules,
followed by any namespace element.

this would give the following structure: [Reemoved modules and extensions from segment, anticipating the resegmentation solution]

On 26/06/2013 13:08, Dr. David Filip wrote:

Did you want all extended elements come last?

Thanks

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