Re: [xliff] Re csprd01 comment 006 was: Fwd: what was our position on co

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

<xliff> 1

+---<file> +

     +---<skeleton> ?

     +---<mda:metadata> ?

     +---<res:resourceData> *

     +---<slr:profile> ?

     +---<val:validation> ?

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

     +---<group> *

     |   |

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

     |   |

     |   +---<mda:metadata> ?

     |   |

     |   +---<val:validation> ?

     |   |

     |   +---<any> *

     +---<unit> *

     |   |

     |   +---<segment> +

     |   |   |

     |   |   +---<source> 1

     |   |   |

     |   |   +---<target> ?

     |   |   |

     |   |   +---<notes> ?

     |   |   |    |

     |   |   |    +---<note> +

     |   |   |

     |   |

     |   +---<ignorable> *

     |   |   |

     |   |   +---<source> 1

     |   |   |

     |   |   +---<target> ?

     |   |

     |   +---<notes> ?

     |   |   |

     |   |   +---<note> +

     |   |

     |   +---<originalData> ?

     |   |       |

     |   |       +---<data> +

     |   |

     |   +---<mtc:matches> ?

     |   |

     |   +---<gls:glossary> ?

     |   |

     |   +---<mda:metadata> ?

     |   |

     |   +---<ctr:changeTrack> ?

     |   |

     |   +---<val:validation> ?

     |   |

     |   +---<any> *

     +---<any> *

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

xliff message