OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only
Expand all | Collapse all

csprod01 comments 018, 024, 028, 036, 050 and F2F meeting - Extending the Glossary module.

  • 1.  csprod01 comments 018, 024, 028, 036, 050 and F2F meeting - Extending the Glossary module.

    Posted 06-28-2013 20:56
    Hi All,   I would like to put forth two proposals for extending the glossary module based on comment 018, 024, 028, 036, 050 and the discussion we had in the F2F in London. I propose the following:   1.       Add an id attribute to <glossentry> so that it can be referenced by a term annotation. 2.       Add a ref attribute to <glossentry> to reference a <segment> within the scope of a <unit> where segmentation/re-segmentation can occur. 3.       Change the source attribute on <definition> to be optional. 4.       EITHER a.       Add <mda:metadata> to <glossentry> OR b.       Allow elements from any namespace in <glossentry>   I would prefer 4.a because then tool implementers could at least treat the data in a way that is consistent with metadata overall.   Here are examples of the proposal:   <unit>   <segment id="s1">     <source>Hello <mrk id="m1" type="term" ref="#g1">World</mrk></source>   </segment>   … </unit> <gls:glossary>   <glossentry id="g1" ref="s1">     <term></term>     <translation></translation>     <definition></definition>     <mda:metadata></mda:metadata>   </glossentry> </gls:glossary>   <unit>   <segment id="s1">     <source>Hello <mrk id="m1" type="term" ref="#g1">World</mrk></source>   </segment>   … </unit> <gls:glossary>   <glossentry id="g1" ref="s1">     <term></term>     <translation></translation>     <definition></definition>     <xyz:any></xyz:any>   </glossentry> </gls:glossary>   Thanks for your consideration, Ryan


  • 2.  RE: csprod01 comments 018, 024, 028, 036, 050 and F2F meeting - Extending the Glossary module.

    Posted 07-01-2013 19:58
    Hi All,   Regarding David’s comments in “Actions (to be) Taken” on the Issue Tracker on comment 018:   A] make Glossary Module more expressive: 1) make <glossentry> extensible by both elements and attributes, 2) make children extensible by attributes, 3) Introduce id to be able to reference back from <mrk type="term">; B] Remove <glossary> from <file> // duplicate of 36 and 50 (master)   In the F2F in London, I think we talked about only allowing elements from any namespace in <glossentry>, however, if people are ok with the level of extensibility David suggests above, I think this will be more consistent with the level of extensibility that exists in other modules. So, I’m updating item 4.b in the proposal to the following:   1.       Add an id attribute to <glossentry> so that it can be referenced by a term annotation. 2.       Add a ref attribute to <glossentry> to reference a <segment> within the scope of a <unit> where segmentation/re-segmentation can occur. 3.       Change the source attribute on <definition> to be optional. 4.       EITHER a.       Add <mda:metadata> to <glossentry> OR b.       Allow elements and attributes from any namespace in <glossentry> and allow attributes from any namespace in children of <glossentry>     From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King Sent: Friday, June 28, 2013 1:55 PM To: xliff@lists.oasis-open.org Subject: [xliff] csprod01 comments 018, 024, 028, 036, 050 and F2F meeting - Extending the Glossary module.   Hi All,   I would like to put forth two proposals for extending the glossary module based on comment 018, 024, 028, 036, 050 and the discussion we had in the F2F in London. I propose the following:   1.       Add an id attribute to <glossentry> so that it can be referenced by a term annotation. 2.       Add a ref attribute to <glossentry> to reference a <segment> within the scope of a <unit> where segmentation/re-segmentation can occur. 3.       Change the source attribute on <definition> to be optional. 4.       EITHER a.       Add <mda:metadata> to <glossentry> OR b.       Allow elements from any namespace in <glossentry>   I would prefer 4.a because then tool implementers could at least treat the data in a way that is consistent with metadata overall.   Here are examples of the proposal:   <unit>   <segment id="s1">     <source>Hello <mrk id="m1" type="term" ref="#g1">World</mrk></source>   </segment>   … </unit> <gls:glossary>   <glossentry id="g1" ref="s1">     <term></term>     <translation></translation>     <definition></definition>     <mda:metadata></mda:metadata>   </glossentry> </gls:glossary>   <unit>   <segment id="s1">     <source>Hello <mrk id="m1" type="term" ref="#g1">World</mrk></source>   </segment>   … </unit> <gls:glossary>   <glossentry id="g1" ref="s1">     <term></term>     <translation></translation>     <definition></definition>     <xyz:any></xyz:any>   </glossentry> </gls:glossary>   Thanks for your consideration, Ryan