XLIFF Inline Markup SC

XLIFF Inline Markup Subcommittee Teleconference - Summary Every second Tuesday of every month at 14:00 UTC 7:00am PT, 8:00am MT, 10:00am ET 3:00pm London, 4:00pm Berlin Teleconference meeting place: https://www1.gotomeeting.com/join/408998929 Meeting ID: 408-998-929 You can use the following US phone number, or the VOIP option provided by GoToMeeting: Dial 630-869-1010 Access Code: 408-998-929 Present: Yves, Jungwoo, Fredrik, Regrets: Christian Latest draft is here: See http://tools.oasis-open.org/version-control/svn/xliff/trunk/xliff-20/xliff-core.pdf === Implementing F2F main changes -- composite values for the type attribute Something like this: type ::= <category>['/'<subcategory>] <subcategory> ::= <authority>':'<value> Or two attributes: Like type and subType (or custType, or xType, or extType), with same values. Need to define the values for the main category. F: single attribute feels best solution to me. Y: tend to agree. J: single was what we agree in F2F J will try to come up with an initial list Y, F to try to do the same. === Bi-directionality details Done in schema, specifications and test implementation (only dir in data is missing in test implementation). Y: Nothing new. Will work on getting the missing dir in data F: Had a quick look at current draft and it looked ok === Annotations representation ACTION ITEM: yves to work on implementation. -> in progress ACTION ITEM: Yves to edit the draft to reflect the sm/em change -> Done. Also: <note> has an id now, so it can be used with comment annotation. === Elements and Attributes Names Time to start choosing final names for the inline markup. See spreadsheet here: https://docs.google.com/spreadsheet/pub?key=0Av8I1YVQlYmsdEwtZ0VEVmo5Y0ZLTndEcUlFMzZnZmc&output=html Either enter suggestion in your column (add one if needed) (ask for the link to the editable table if you don't have it any more, or post an email with the suggestions) ACTION ITEM: Yves to remind everyone. === Namespace? We need to decide to which namespace the content markup should belong. a- same as the core namespace b- one separate namespace (but still belong to the core) c- several separate namespaces (e.g. codes still belong to the core, but not annotations, etc.) Y: prefer option a F: like concept of separate ns in core, but see advantage of having it in the core ns. Feel separate ns would make it easier for separate use. Using several namespaces for inline would not bring anything. J: option a looks best === Any other business TMX has looked at our model a bit. Y: max size feature? F: working on it. It would add an additional attribute in inline markup, as separate module. -end

Big apology for being so late. Here is my first draft. There are several ways of categorising tags, but I tried to reduce as much as possible to have only a list of items meaningful to translation. Examples include tags from HTML5, which is expected to be in more matured status when XLIFF 2.0 is released. I did not give much attention to the types in grey. We cannot have a definite classification for all tags. <address> by its nature, is not a formatting tag for example, but practically acts as a non-critical formatting tag at rendering moment. type is more to give a hint to translators/translation tools than defining grouping. Type SubType Description Example fmt [Formatting] Majority of embedded elements would belong to here. Generally loss of these in-line elements is not critical to translation. But some may be. font, code, br, em, strong, small, big, i,b,u, dfn, samp, var, mark, span, ins, del, kbd, sub, sup, address, bdi, bdo, meter, br, center, strike, wbr quot In-line quotation. These should be translated as an independent group. Also a good hint to MT. q, cite (title of a work) link Link (Anchor). Loss of tags is critical to the quality of translated material. a, xlink, ulink annot Annotation. Providing additional information. abbr, ruby, time, acronym bidi Bi-Di related bdi, bdo struct List, Bullet point. Tables etc.. option, td, li, dt, dd, optgroup section Document Structure, Block h1, h2, h3, div, footer, header, div, p, pre, blockquote embed Embedded objects img, embed, video, object, audio, iframe script Dynamic scripts script form Form elements input, button gen Generic purpose or Uncategorized Jung On 11/09/2012 15:31, Yves Savourel wrote: XLIFF Inline Markup Subcommittee Teleconference - Summary Every second Tuesday of every month at 14:00 UTC 7:00am PT, 8:00am MT, 10:00am ET 3:00pm London, 4:00pm Berlin Teleconference meeting place: https://www1.gotomeeting.com/join/408998929 Meeting ID: 408-998-929 You can use the following US phone number, or the VOIP option provided by GoToMeeting: Dial 630-869-1010 Access Code: 408-998-929 Present: Yves, Jungwoo, Fredrik, Regrets: Christian Latest draft is here: See http://tools.oasis-open.org/version-control/svn/xliff/trunk/xliff-20/xliff-core.pdf === Implementing F2F main changes -- composite values for the type attribute Something like this: type ::= <category>['/'<subcategory>] <subcategory> ::= <authority>':'<value> Or two attributes: Like type and subType (or custType, or xType, or extType), with same values. Need to define the values for the main category. F: single attribute feels best solution to me. Y: tend to agree. J: single was what we agree in F2F J will try to come up with an initial list Y, F to try to do the same. === Bi-directionality details Done in schema, specifications and test implementation (only dir in data is missing in test implementation). Y: Nothing new. Will work on getting the missing dir in data F: Had a quick look at current draft and it looked ok === Annotations representation ACTION ITEM: yves to work on implementation. -> in progress ACTION ITEM: Yves to edit the draft to reflect the sm/em change -> Done. Also: <note> has an id now, so it can be used with comment annotation. === Elements and Attributes Names Time to start choosing final names for the inline markup. See spreadsheet here: https://docs.google.com/spreadsheet/pub?key=0Av8I1YVQlYmsdEwtZ0VEVmo5Y0ZLTndEcUlFMzZnZmc&output=html Either enter suggestion in your column (add one if needed) (ask for the link to the editable table if you don't have it any more, or post an email with the suggestions) ACTION ITEM: Yves to remind everyone. === Namespace? We need to decide to which namespace the content markup should belong. a- same as the core namespace b- one separate namespace (but still belong to the core) c- several separate namespaces (e.g. codes still belong to the core, but not annotations, etc.) Y: prefer option a F: like concept of separate ns in core, but see advantage of having it in the core ns. Feel separate ns would make it easier for separate use. Using several namespaces for inline would not bring anything. J: option a looks best === Any other business TMX has looked at our model a bit. Y: max size feature? F: working on it. It would add an additional attribute in inline markup, as separate module. -end --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org -- Jung Nicholas Ryoo Principal Software Engineer Phone: +35318031918 Fax: +35318031918 Oracle WPTG Infrastructure ORACLE Ireland Block P5, Eastpoint Business Park Dublin 3 Oracle is committed to developing practices and products that help protect the environment

Hi,   This reminds me of categorizations that I have seen elsewhere …   1.        List we compiled for ITS 1.0 (see http://www.w3.org/International/its/requirements/Overview.html#mapping ); example: elements associated with specific text styles 2.        Categories used in the Darwin Information Typing Architecture (DTIA; see http://docs.oasis-open.org/dita/v1.2/os/spec/DITA1.2-spec.html ); examples: basic, body, related links, typographic elements 3.        Categories used in HTML5 (see http://dev.w3.org/html5/spec/single-page.html ); examples: sections, grouping content, text-level semantics   I am always in favour of being knowledgable about what already exists.   Cheers, Christian   From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Jung Nicholas Ryoo Sent: Montag, 1. Oktober 2012 11:59 To: xliff-inline@lists.oasis-open.org Subject: Re: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Sep-11-2012 - Summary   Big apology for being so late. Here is my first draft. There are several ways of categorising tags, but I tried to reduce as much as possible to have only a list of items meaningful to translation. Examples include tags from HTML5, which is expected to be in more matured status when XLIFF 2.0 is released. I did not give much attention to the types in grey. We cannot have a definite classification for all tags. <address> by its nature, is not a formatting tag for example, but practically acts as a non-critical formatting tag at rendering moment. "type" is more to give a hint to translators/translation tools than defining grouping. Type SubType Description Example fmt [Formatting] Majority of embedded elements would belong to here. Generally loss of these in-line elements is not critical to translation. But some may be. font, code, br, em, strong, small, big, i,b,u, dfn, samp, var, mark, span, ins, del, kbd, sub, sup, address, bdi, bdo, meter, br, center, strike, wbr quot In-line quotation. These should be translated as an independent group. Also a good hint to MT. q, cite (title of a work) link Link (Anchor). Loss of tags is critical to the quality of translated material. a, xlink, ulink annot Annotation. Providing additional information. abbr, ruby, time, acronym bidi Bi-Di related bdi, bdo struct List, Bullet point. Tables etc.. option, td, li, dt, dd, optgroup section Document Structure, Block h1, h2, h3, div, footer, header, div, p, pre, blockquote embed Embedded objects img, embed, video, object, audio, iframe script Dynamic scripts script form Form elements input, button gen Generic purpose or Uncategorized Jung On 11/09/2012 15:31, Yves Savourel wrote: XLIFF Inline Markup Subcommittee Teleconference - Summary   Every second Tuesday of every month at 14:00 UTC 7:00am PT, 8:00am MT, 10:00am ET 3:00pm London, 4:00pm Berlin   Teleconference meeting place: https://www1.gotomeeting.com/join/408998929 Meeting ID: 408-998-929 You can use the following US phone number, or the VOIP option provided by GoToMeeting: Dial 630-869-1010 Access Code: 408-998-929   Present: Yves, Jungwoo, Fredrik, Regrets: Christian     Latest draft is here: See http://tools.oasis-open.org/version-control/svn/xliff/trunk/xliff-20/xliff-core.pdf     === Implementing F2F main changes   -- composite values for the type attribute Something like this:   type ::= <category>['/'<subcategory>] <subcategory> ::= <authority>':'<value>   Or two attributes:   Like type and subType (or custType, or xType, or extType), with same values.   Need to define the values for the main category.   F: single attribute feels best solution to me. Y: tend to agree. J: single was what we agree in F2F   J will try to come up with an initial list Y, F to try to do the same.       === Bi-directionality details   Done in schema, specifications and test implementation (only dir in data is missing in test implementation).   Y: Nothing new. Will work on getting the missing dir in data F: Had a quick look at current draft and it looked ok       === Annotations representation   ACTION ITEM: yves to work on implementation. -> in progress   ACTION ITEM: Yves to edit the draft to reflect the sm/em change -> Done.   Also: <note> has an id now, so it can be used with comment annotation.       === Elements and Attributes Names   Time to start choosing final names for the inline markup.   See spreadsheet here: https://docs.google.com/spreadsheet/pub?key=0Av8I1YVQlYmsdEwtZ0VEVmo5Y0ZLTndEcUlFMzZnZmc&output=html   Either enter suggestion in your column (add one if needed) (ask for the link to the editable table if you don't have it any more, or post an email with the suggestions)   ACTION ITEM: Yves to remind everyone.       === Namespace?   We need to decide to which namespace the content markup should belong.   a- same as the core namespace b- one separate namespace (but still belong to the core) c- several separate namespaces (e.g. codes still belong to the core, but not annotations, etc.)   Y: prefer option a F: like concept of separate ns in core, but see advantage of having it in the core ns. Feel separate ns would make it easier for separate use. Using several namespaces for inline would not bring anything. J: option a looks best     === Any other business   TMX has looked at our model a bit.   Y: max size feature? F: working on it. It would add an additional attribute in inline markup, as separate module.   -end           --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org         -- Jung Nicholas Ryoo Principal Software Engineer Phone: +35318031918 Fax: +35318031918 Oracle WPTG Infrastructure ORACLE Ireland Block P5, Eastpoint Business Park Dublin 3 Oracle is committed to developing practices and products that help protect the environment

Hi Christian,   Good pointers. Looking at those, do you have a list of possible values that would complement what Jung came up with?   Cheers, -yves     From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Lieske, Christian Sent: Monday, October 01, 2012 5:58 AM To: Jung Nicholas Ryoo; xliff-inline@lists.oasis-open.org Subject: RE: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Sep-11-2012 - Summary   Hi,   This reminds me of categorizations that I have seen elsewhere …   1.        List we compiled for ITS 1.0 (see http://www.w3.org/International/its/requirements/Overview.html#mapping ); example: elements associated with specific text styles 2.        Categories used in the Darwin Information Typing Architecture (DTIA; see http://docs.oasis-open.org/dita/v1.2/os/spec/DITA1.2-spec.html ); examples: basic, body, related links, typographic elements 3.        Categories used in HTML5 (see http://dev.w3.org/html5/spec/single-page.html ); examples: sections, grouping content, text-level semantics   I am always in favour of being knowledgable about what already exists.   Cheers, Christian   From: xliff-inline@lists.oasis-open.org [ mailto:xliff-inline@lists.oasis-open.org ] On Behalf Of Jung Nicholas Ryoo Sent: Montag, 1. Oktober 2012 11:59 To: xliff-inline@lists.oasis-open.org Subject: Re: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Sep-11-2012 - Summary   Big apology for being so late. Here is my first draft. There are several ways of categorising tags, but I tried to reduce as much as possible to have only a list of items meaningful to translation. Examples include tags from HTML5, which is expected to be in more matured status when XLIFF 2.0 is released. I did not give much attention to the types in grey. We cannot have a definite classification for all tags. <address> by its nature, is not a formatting tag for example, but practically acts as a non-critical formatting tag at rendering moment. "type" is more to give a hint to translators/translation tools than defining grouping. Type SubType Description Example fmt [Formatting] Majority of embedded elements would belong to here. Generally loss of these in-line elements is not critical to translation. But some may be. font, code, br, em, strong, small, big, i,b,u, dfn, samp, var, mark, span, ins, del, kbd, sub, sup, address, bdi, bdo, meter, br, center, strike, wbr quot In-line quotation. These should be translated as an independent group. Also a good hint to MT. q, cite (title of a work) link Link (Anchor). Loss of tags is critical to the quality of translated material. a, xlink, ulink annot Annotation. Providing additional information. abbr, ruby, time, acronym bidi Bi-Di related bdi, bdo struct List, Bullet point. Tables etc.. option, td, li, dt, dd, optgroup section Document Structure, Block h1, h2, h3, div, footer, header, div, p, pre, blockquote embed Embedded objects img, embed, video, object, audio, iframe script Dynamic scripts script form Form elements input, button gen Generic purpose or Uncategorized Jung On 11/09/2012 15:31, Yves Savourel wrote: XLIFF Inline Markup Subcommittee Teleconference - Summary   Every second Tuesday of every month at 14:00 UTC 7:00am PT, 8:00am MT, 10:00am ET 3:00pm London, 4:00pm Berlin   Teleconference meeting place: https://www1.gotomeeting.com/join/408998929 Meeting ID: 408-998-929 You can use the following US phone number, or the VOIP option provided by GoToMeeting: Dial 630-869-1010 Access Code: 408-998-929   Present: Yves, Jungwoo, Fredrik, Regrets: Christian     Latest draft is here: See http://tools.oasis-open.org/version-control/svn/xliff/trunk/xliff-20/xliff-core.pdf     === Implementing F2F main changes   -- composite values for the type attribute Something like this:   type ::= <category>['/'<subcategory>] <subcategory> ::= <authority>':'<value>   Or two attributes:   Like type and subType (or custType, or xType, or extType), with same values.   Need to define the values for the main category.   F: single attribute feels best solution to me. Y: tend to agree. J: single was what we agree in F2F   J will try to come up with an initial list Y, F to try to do the same.       === Bi-directionality details   Done in schema, specifications and test implementation (only dir in data is missing in test implementation).   Y: Nothing new. Will work on getting the missing dir in data F: Had a quick look at current draft and it looked ok       === Annotations representation   ACTION ITEM: yves to work on implementation. -> in progress   ACTION ITEM: Yves to edit the draft to reflect the sm/em change -> Done.   Also: <note> has an id now, so it can be used with comment annotation.       === Elements and Attributes Names   Time to start choosing final names for the inline markup.   See spreadsheet here: https://docs.google.com/spreadsheet/pub?key=0Av8I1YVQlYmsdEwtZ0VEVmo5Y0ZLTndEcUlFMzZnZmc&output=html   Either enter suggestion in your column (add one if needed) (ask for the link to the editable table if you don't have it any more, or post an email with the suggestions)   ACTION ITEM: Yves to remind everyone.       === Namespace?   We need to decide to which namespace the content markup should belong.   a- same as the core namespace b- one separate namespace (but still belong to the core) c- several separate namespaces (e.g. codes still belong to the core, but not annotations, etc.)   Y: prefer option a F: like concept of separate ns in core, but see advantage of having it in the core ns. Feel separate ns would make it easier for separate use. Using several namespaces for inline would not bring anything. J: option a looks best     === Any other business   TMX has looked at our model a bit.   Y: max size feature? F: working on it. It would add an additional attribute in inline markup, as separate module.   -end           --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org         -- Jung Nicholas Ryoo Principal Software Engineer Phone: +35318031918 Fax: +35318031918 Oracle WPTG Infrastructure ORACLE Ireland Block P5, Eastpoint Business Park Dublin 3 Oracle is committed to developing practices and products that help protect the environment

Hi Yves and Christian, Thank you very much. Yes, I checked HTML5 categorisation before having the initial list. section was one example I borrowed name from it. What I have found here and there was all major types of mark-up language instances such as HTML, DITA and DocBook ( Categories of Elements in DocBook ) have their own categories. I thought It would not be too realistic for XLIFF to follow all such categories. And the purpose of having type attribute in XLIFF wouldn't be exactly same as having category in each doctype's specification. IMHO, type in XLIFF should be a useful hint to translators and to CATs. So, the question I had was, what can translators/CATs do according to the type value. I thought the tools (people) could apply different level of QA priority/task and different quality expectation depending whether the type of the in-line element is for formatting or for linking to external/internal resources. Example cases) fmt type was to target formatting elements. Missing or incorrect positions of these elements may not have large impact on overall quality. quot (or 'island' in Oracle's terminology) type was to target elements with a floating text or a long book title that must be translated as a group. link : Anchors. Usually its position and value are very critical ... jung On 01/10/2012 13:49, Yves Savourel wrote: Hi Christian,   Good pointers. Looking at those, do you have a list of possible values that would complement what Jung came up with?   Cheers, -yves     From: xliff-inline@lists.oasis-open.org [ mailto:xliff-inline@lists.oasis-open.org ] On Behalf Of Lieske, Christian Sent: Monday, October 01, 2012 5:58 AM To: Jung Nicholas Ryoo; xliff-inline@lists.oasis-open.org Subject: RE: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Sep-11-2012 - Summary   Hi,   This reminds me of categorizations that I have seen elsewhere …   1.        List we compiled for ITS 1.0 (see http://www.w3.org/International/its/requirements/Overview.html#mapping ); example: elements associated with specific text styles 2.        Categories used in the Darwin Information Typing Architecture (DTIA; see http://docs.oasis-open.org/dita/v1.2/os/spec/DITA1.2-spec.html ); examples: basic, body, related links, typographic elements 3.        Categories used in HTML5 (see http://dev.w3.org/html5/spec/single-page.html ); examples: sections, grouping content, text-level semantics   I am always in favour of being knowledgable about what already exists.   Cheers, Christian   From: xliff-inline@lists.oasis-open.org [ mailto:xliff-inline@lists.oasis-open.org ] On Behalf Of Jung Nicholas Ryoo Sent: Montag, 1. Oktober 2012 11:59 To: xliff-inline@lists.oasis-open.org Subject: Re: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Sep-11-2012 - Summary   Big apology for being so late. Here is my first draft. There are several ways of categorising tags, but I tried to reduce as much as possible to have only a list of items meaningful to translation. Examples include tags from HTML5, which is expected to be in more matured status when XLIFF 2.0 is released. I did not give much attention to the types in grey. We cannot have a definite classification for all tags. <address> by its nature, is not a formatting tag for example, but practically acts as a non-critical formatting tag at rendering moment. type is more to give a hint to translators/translation tools than defining grouping. Type SubType Description Example fmt [Formatting] Majority of embedded elements would belong to here. Generally loss of these in-line elements is not critical to translation. But some may be. font, code, br, em, strong, small, big, i,b,u, dfn, samp, var, mark, span, ins, del, kbd, sub, sup, address, bdi, bdo, meter, br, center, strike, wbr quot In-line quotation. These should be translated as an independent group. Also a good hint to MT. q, cite (title of a work) link Link (Anchor). Loss of tags is critical to the quality of translated material. a, xlink, ulink annot Annotation. Providing additional information. abbr, ruby, time, acronym bidi Bi-Di related bdi, bdo struct List, Bullet point. Tables etc.. option, td, li, dt, dd, optgroup section Document Structure, Block h1, h2, h3, div, footer, header, div, p, pre, blockquote embed Embedded objects img, embed, video, object, audio, iframe script Dynamic scripts script form Form elements input, button gen Generic purpose or Uncategorized Jung On 11/09/2012 15:31, Yves Savourel wrote: XLIFF Inline Markup Subcommittee Teleconference - Summary   Every second Tuesday of every month at 14:00 UTC 7:00am PT, 8:00am MT, 10:00am ET 3:00pm London, 4:00pm Berlin   Teleconference meeting place: https://www1.gotomeeting.com/join/408998929 Meeting ID: 408-998-929 You can use the following US phone number, or the VOIP option provided by GoToMeeting: Dial 630-869-1010 Access Code: 408-998-929   Present: Yves, Jungwoo, Fredrik, Regrets: Christian     Latest draft is here: See http://tools.oasis-open.org/version-control/svn/xliff/trunk/xliff-20/xliff-core.pdf     === Implementing F2F main changes   -- composite values for the type attribute Something like this:   type ::= <category>['/'<subcategory>] <subcategory> ::= <authority>':'<value>   Or two attributes:   Like type and subType (or custType, or xType, or extType), with same values.   Need to define the values for the main category.   F: single attribute feels best solution to me. Y: tend to agree. J: single was what we agree in F2F   J will try to come up with an initial list Y, F to try to do the same.       === Bi-directionality details   Done in schema, specifications and test implementation (only dir in data is missing in test implementation).   Y: Nothing new. Will work on getting the missing dir in data F: Had a quick look at current draft and it looked ok       === Annotations representation   ACTION ITEM: yves to work on implementation. -> in progress   ACTION ITEM: Yves to edit the draft to reflect the sm/em change -> Done.   Also: <note> has an id now, so it can be used with comment annotation.       === Elements and Attributes Names   Time to start choosing final names for the inline markup.   See spreadsheet here: https://docs.google.com/spreadsheet/pub?key=0Av8I1YVQlYmsdEwtZ0VEVmo5Y0ZLTndEcUlFMzZnZmc&output=html   Either enter suggestion in your column (add one if needed) (ask for the link to the editable table if you don't have it any more, or post an email with the suggestions)   ACTION ITEM: Yves to remind everyone.       === Namespace?   We need to decide to which namespace the content markup should belong.   a- same as the core namespace b- one separate namespace (but still belong to the core) c- several separate namespaces (e.g. codes still belong to the core, but not annotations, etc.)   Y: prefer option a F: like concept of separate ns in core, but see advantage of having it in the core ns. Feel separate ns would make it easier for separate use. Using several namespaces for inline would not bring anything. J: option a looks best     === Any other business   TMX has looked at our model a bit.   Y: max size feature? F: working on it. It would add an additional attribute in inline markup, as separate module.   -end           --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org         -- Jung Nicholas Ryoo Principal Software Engineer Phone: +35318031918 Fax: +35318031918 Oracle WPTG Infrastructure ORACLE Ireland Block P5, Eastpoint Business Park Dublin 3 Oracle is committed to developing practices and products that help protect the environment -- Jung Nicholas Ryoo Principal Software Engineer Phone: +35318031918 Fax: +35318031918 Oracle WPTG Infrastructure ORACLE Ireland Block P5, Eastpoint Business Park Dublin 3 Oracle is committed to developing practices and products that help protect the environment

Hi,   Not sure where to start … I guess it would be advantageous to define whether one would like to focus on structural, semantic, or presentational categories (see the list of “context” types in   http://www.w3.org/International/its/wiki/IssuesAndProposedFeatures#Proposal:_.22Context.22_data_category ).   In any case I think we should aim at clear “representation guides” in the sense that for example any ‘em’ inline that originates in HTML5-based content shall be categorized as type X and sub-type Y. Approaching it from another ankle one could say that one would need to try to create these guides for a couple of relevant native formats in order to find out which categories would be adequate. Presumably, that could only be done in a collaborative effort.   Cheers, Christian     From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Montag, 1. Oktober 2012 14:49 To: xliff-inline@lists.oasis-open.org Subject: RE: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Sep-11-2012 - Summary   Hi Christian,   Good pointers. Looking at those, do you have a list of possible values that would complement what Jung came up with?   Cheers, -yves     From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Lieske, Christian Sent: Monday, October 01, 2012 5:58 AM To: Jung Nicholas Ryoo; xliff-inline@lists.oasis-open.org Subject: RE: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Sep-11-2012 - Summary   Hi,   This reminds me of categorizations that I have seen elsewhere …   1.        List we compiled for ITS 1.0 (see http://www.w3.org/International/its/requirements/Overview.html#mapping ); example: elements associated with specific text styles 2.        Categories used in the Darwin Information Typing Architecture (DTIA; see http://docs.oasis-open.org/dita/v1.2/os/spec/DITA1.2-spec.html ); examples: basic, body, related links, typographic elements 3.        Categories used in HTML5 (see http://dev.w3.org/html5/spec/single-page.html ); examples: sections, grouping content, text-level semantics   I am always in favour of being knowledgable about what already exists.   Cheers, Christian   From: xliff-inline@lists.oasis-open.org [ mailto:xliff-inline@lists.oasis-open.org ] On Behalf Of Jung Nicholas Ryoo Sent: Montag, 1. Oktober 2012 11:59 To: xliff-inline@lists.oasis-open.org Subject: Re: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Sep-11-2012 - Summary   Big apology for being so late. Here is my first draft. There are several ways of categorising tags, but I tried to reduce as much as possible to have only a list of items meaningful to translation. Examples include tags from HTML5, which is expected to be in more matured status when XLIFF 2.0 is released. I did not give much attention to the types in grey. We cannot have a definite classification for all tags. <address> by its nature, is not a formatting tag for example, but practically acts as a non-critical formatting tag at rendering moment. "type" is more to give a hint to translators/translation tools than defining grouping. Type SubType Description Example fmt [Formatting] Majority of embedded elements would belong to here. Generally loss of these in-line elements is not critical to translation. But some may be. font, code, br, em, strong, small, big, i,b,u, dfn, samp, var, mark, span, ins, del, kbd, sub, sup, address, bdi, bdo, meter, br, center, strike, wbr quot In-line quotation. These should be translated as an independent group. Also a good hint to MT. q, cite (title of a work) link Link (Anchor). Loss of tags is critical to the quality of translated material. a, xlink, ulink annot Annotation. Providing additional information. abbr, ruby, time, acronym bidi Bi-Di related bdi, bdo struct List, Bullet point. Tables etc.. option, td, li, dt, dd, optgroup section Document Structure, Block h1, h2, h3, div, footer, header, div, p, pre, blockquote embed Embedded objects img, embed, video, object, audio, iframe script Dynamic scripts script form Form elements input, button gen Generic purpose or Uncategorized Jung On 11/09/2012 15:31, Yves Savourel wrote: XLIFF Inline Markup Subcommittee Teleconference - Summary   Every second Tuesday of every month at 14:00 UTC 7:00am PT, 8:00am MT, 10:00am ET 3:00pm London, 4:00pm Berlin   Teleconference meeting place: https://www1.gotomeeting.com/join/408998929 Meeting ID: 408-998-929 You can use the following US phone number, or the VOIP option provided by GoToMeeting: Dial 630-869-1010 Access Code: 408-998-929   Present: Yves, Jungwoo, Fredrik, Regrets: Christian     Latest draft is here: See http://tools.oasis-open.org/version-control/svn/xliff/trunk/xliff-20/xliff-core.pdf     === Implementing F2F main changes   -- composite values for the type attribute Something like this:   type ::= <category>['/'<subcategory>] <subcategory> ::= <authority>':'<value>   Or two attributes:   Like type and subType (or custType, or xType, or extType), with same values.   Need to define the values for the main category.   F: single attribute feels best solution to me. Y: tend to agree. J: single was what we agree in F2F   J will try to come up with an initial list Y, F to try to do the same.       === Bi-directionality details   Done in schema, specifications and test implementation (only dir in data is missing in test implementation).   Y: Nothing new. Will work on getting the missing dir in data F: Had a quick look at current draft and it looked ok       === Annotations representation   ACTION ITEM: yves to work on implementation. -> in progress   ACTION ITEM: Yves to edit the draft to reflect the sm/em change -> Done.   Also: <note> has an id now, so it can be used with comment annotation.       === Elements and Attributes Names   Time to start choosing final names for the inline markup.   See spreadsheet here: https://docs.google.com/spreadsheet/pub?key=0Av8I1YVQlYmsdEwtZ0VEVmo5Y0ZLTndEcUlFMzZnZmc&output=html   Either enter suggestion in your column (add one if needed) (ask for the link to the editable table if you don't have it any more, or post an email with the suggestions)   ACTION ITEM: Yves to remind everyone.       === Namespace?   We need to decide to which namespace the content markup should belong.   a- same as the core namespace b- one separate namespace (but still belong to the core) c- several separate namespaces (e.g. codes still belong to the core, but not annotations, etc.)   Y: prefer option a F: like concept of separate ns in core, but see advantage of having it in the core ns. Feel separate ns would make it easier for separate use. Using several namespaces for inline would not bring anything. J: option a looks best     === Any other business   TMX has looked at our model a bit.   Y: max size feature? F: working on it. It would add an additional attribute in inline markup, as separate module.   -end           --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org         -- Jung Nicholas Ryoo Principal Software Engineer Phone: +35318031918 Fax: +35318031918 Oracle WPTG Infrastructure ORACLE Ireland Block P5, Eastpoint Business Park Dublin 3 Oracle is committed to developing practices and products that help protect the environment

Hi Jung,   Thanks for the initial list.   I’m guessing the grayed items are probably out of scope since we are dealing with the type attriute of the in-line codes. I wonder about ‘struct’. By definition, if it’s a structural code it probably should not be extracted as in-line in XLIFF.   -yves     From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Jung Nicholas Ryoo Sent: Monday, October 01, 2012 3:59 AM To: xliff-inline@lists.oasis-open.org Subject: Re: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Sep-11-2012 - Summary   Big apology for being so late. Here is my first draft. There are several ways of categorising tags, but I tried to reduce as much as possible to have only a list of items meaningful to translation. Examples include tags from HTML5, which is expected to be in more matured status when XLIFF 2.0 is released. I did not give much attention to the types in grey. We cannot have a definite classification for all tags. <address> by its nature, is not a formatting tag for example, but practically acts as a non-critical formatting tag at rendering moment. "type" is more to give a hint to translators/translation tools than defining grouping. Type SubType Description Example fmt [Formatting] Majority of embedded elements would belong to here. Generally loss of these in-line elements is not critical to translation. But some may be. font, code, br, em, strong, small, big, i,b,u, dfn, samp, var, mark, span, ins, del, kbd, sub, sup, address, bdi, bdo, meter, br, center, strike, wbr quot In-line quotation. These should be translated as an independent group. Also a good hint to MT. q, cite (title of a work) link Link (Anchor). Loss of tags is critical to the quality of translated material. a, xlink, ulink annot Annotation. Providing additional information. abbr, ruby, time, acronym bidi Bi-Di related bdi, bdo struct List, Bullet point. Tables etc.. option, td, li, dt, dd, optgroup section Document Structure, Block h1, h2, h3, div, footer, header, div, p, pre, blockquote embed Embedded objects img, embed, video, object, audio, iframe script Dynamic scripts script form Form elements input, button gen Generic purpose or Uncategorized Jung On 11/09/2012 15:31, Yves Savourel wrote: XLIFF Inline Markup Subcommittee Teleconference - Summary   Every second Tuesday of every month at 14:00 UTC 7:00am PT, 8:00am MT, 10:00am ET 3:00pm London, 4:00pm Berlin   Teleconference meeting place: https://www1.gotomeeting.com/join/408998929 Meeting ID: 408-998-929 You can use the following US phone number, or the VOIP option provided by GoToMeeting: Dial 630-869-1010 Access Code: 408-998-929   Present: Yves, Jungwoo, Fredrik, Regrets: Christian     Latest draft is here: See http://tools.oasis-open.org/version-control/svn/xliff/trunk/xliff-20/xliff-core.pdf     === Implementing F2F main changes   -- composite values for the type attribute Something like this:   type ::= <category>['/'<subcategory>] <subcategory> ::= <authority>':'<value>   Or two attributes:   Like type and subType (or custType, or xType, or extType), with same values.   Need to define the values for the main category.   F: single attribute feels best solution to me. Y: tend to agree. J: single was what we agree in F2F   J will try to come up with an initial list Y, F to try to do the same.       === Bi-directionality details   Done in schema, specifications and test implementation (only dir in data is missing in test implementation).   Y: Nothing new. Will work on getting the missing dir in data F: Had a quick look at current draft and it looked ok       === Annotations representation   ACTION ITEM: yves to work on implementation. -> in progress   ACTION ITEM: Yves to edit the draft to reflect the sm/em change -> Done.   Also: <note> has an id now, so it can be used with comment annotation.       === Elements and Attributes Names   Time to start choosing final names for the inline markup.   See spreadsheet here: https://docs.google.com/spreadsheet/pub?key=0Av8I1YVQlYmsdEwtZ0VEVmo5Y0ZLTndEcUlFMzZnZmc&output=html   Either enter suggestion in your column (add one if needed) (ask for the link to the editable table if you don't have it any more, or post an email with the suggestions)   ACTION ITEM: Yves to remind everyone.       === Namespace?   We need to decide to which namespace the content markup should belong.   a- same as the core namespace b- one separate namespace (but still belong to the core) c- several separate namespaces (e.g. codes still belong to the core, but not annotations, etc.)   Y: prefer option a F: like concept of separate ns in core, but see advantage of having it in the core ns. Feel separate ns would make it easier for separate use. Using several namespaces for inline would not bring anything. J: option a looks best     === Any other business   TMX has looked at our model a bit.   Y: max size feature? F: working on it. It would add an additional attribute in inline markup, as separate module.   -end           --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org         -- Jung Nicholas Ryoo Principal Software Engineer Phone: +35318031918 Fax: +35318031918 Oracle WPTG Infrastructure ORACLE Ireland Block P5, Eastpoint Business Park Dublin 3 Oracle is committed to developing practices and products that help protect the environment