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: FW: Generic Inline Markup - Was: RE: Latest draft of TMX 2.0


This is a partial (very abbreviated) summary of the conversation between members of the XLIFF TC and the TMX TC regarding the possibility of simplifying the inline element(s) such that it serves all markup requirements, and is then suitable to be shared between XLIFF and TMX.

- TMX has proposed "<itag>, the new generic inline
tag intended to simplify the markup salad." (Rodolfo's words)
- Magnus commented that <itag> behaves more like <bpt> <ept> than <g>
- Many of us expressed opinions on this (i.e., a markup pair is not a node)

Christian defined an approach for collaborating on a solution (below). Support for this approach is on record from the TMX and XLIFF camps (Arle and Bryan).

Hopefully this summary will be sufficient for us to use as a reference on our meeting agenda.

Thanks,

Bryan


-----Original Message-----
From: Lieske, Christian [mailto:christian.lieske@sap.com]
Sent: Sunday, February 22, 2009 11:35 AM
To: Schnabel, Bryan S; arle@lisa.org; yves@opentag.com; rmraya@maxprograms.com; ddomeny@ektron.com; MMartikainen@sdl.com; tony.jewtushenko@productinnovator.com; asgeirf@redhat.com; azydron@xml-intl.com
Subject: RE: Generic Inline Markup - Was: RE: Latest draft of TMX 2.0


Dear all,

2 positive voices are encouraging but presumably not sufficient. Let's see what the others think.

Here is some more input from my side:

i. Addition to "1. General Scope"
        - enabling for the W3C Internationalization Tag Set (I guess allowing local ITS markup would be sufficient)
ii. Addition to "4. Abstract Markup Proposal"
        - values of individual attributes; semantics of element, attributes and values
        - default values and inheritance rules

Cheers,
Christian

-----Original Message-----
From: bryan.s.schnabel@tektronix.com [mailto:bryan.s.schnabel@tektronix.com]
Sent: Friday, February 20, 2009 4:51 PM
To: arle@lisa.org; Lieske, Christian; yves@opentag.com; rmraya@maxprograms.com; ddomeny@ektron.com; MMartikainen@sdl.com; tony.jewtushenko@productinnovator.com; asgeirf@redhat.com; azydron@xml-intl.com
Subject: RE: Generic Inline Markup - Was: RE: Latest draft of TMX 2.0

I very much support this approach. I think generic inline markup is a realistic goal. I also think a coordinated effort, as Christian described, is feasible. I'd be happy to advocate for this approach on the XLIFF TC.

Bryan

________________________________________
From: Arle Lommel [arle.lommel.lisa@gmail.com] On Behalf Of Arle Lommel [arle@lisa.org]
Sent: Friday, February 20, 2009 5:26 AM
To: Lieske, Christian; Yves Savourel; Rodolfo M. Raya; Doug Domeny; Magnus Martikainen; Tony Jewtushenko; Schnabel, Bryan S; Asgeir Frimannsson; Andrzej Zydron
Subject: Re: Generic Inline Markup - Was: RE: Latest draft of TMX 2.0

In general I support Christianšs idea. If it would be possible to develop a
single, unified approach to content markup that will work properly with a
variety of linguistic technologies that either utilize XML for a direct end
or as a portability mechanism, I would be all in favor. Whether that goal
would be possible remains to be seen, but it should be at least explored. To
my mind it is the "task agnostic" part that may be the hardest to achieve.
Even if it proves impossible, however, we will at least have a clearer
understanding of the issues and obstacles.

-Arle


Lieske, Christian <christian.lieske@sap.com> scripsit

> Dear all,
>
> I wonder if we should start to turn the gist or even the details of our
> discussion into a requirements document. If we do so, we may even want
> to set ourselves a deadline, and possibly use a wiki page for
> collaboration.
>
> Possible dimensions which could show up in the requirements could be:
>
> 1. general scope
>
> - abstract representation for so-called "inline" markup (as
> opposed to for example "block-level" markup)
> - ability for nesting (to take care of sub-flows; cf. W3C ITS
> "elements within text" data category)
> - canonical in the sense that there is only one physical
> representation for a given native representation
> - ability for annotations
> - separation between possibly localizable text, native format
> (includes structural information), and annotations
>  to enable easy parsing/transformation
> - task agnostic in the sense that it is suited in any context
> (translation memory, translation workflow etc.)
>
> 2. relationship to a namespace
>
> - tied to current version or successor of an existing namespace
> (such as TMX or XLIFF)
> - placed in a namespace of its own (to support a modular XML
> content architecture; cf. "xml:lang" or "xml:space")
>
> 3. backwards compatibility with existing namespaces
>
> - yes/no
> - clear migration path in the sense that it is clear how
> existing concepts (for example the ones in TMX or XLIFF)
>  map to the new concept)
>
> 4. abstract markup proposal
>
> - one or two new tags
>
> 5. specific markup proposal
>
> - name of tag 1, attributes for tag 1, values of individual
> attributes; semantics of element, attributes and values
>
> Cheers,
> Christian
>
> -----Original Message-----
> From: Yves Savourel [mailto:yves@opentag.com]
> Sent: Friday, February 20, 2009 12:18 AM
> To: 'Rodolfo M. Raya'; 'Doug Domeny'
> Cc: 'Arle Lommel'; 'Magnus Martikainen'; 'Tony Jewtushenko'; 'Bryan
> Schnabel'; Lieske, Christian; 'Asgeir Frimannsson'; 'Andrzej Zydron'
> Subject: RE: Latest draft of TMX 2.0
>
>> To solve this issue, a unique tag is needed. Having 2 tags, with any
>> name, isn't good. It is necessary to discard having <x> and <g>
>> functionality.
>>
>> Hope you understand why we would like to have just one tag in TMX.
>
> Just to be more specific:
>
> There are 3 type of codes in TMX and XLIFF: staring, ending, and
> stand-alone.
>
> Regardless how you represent them: one, two or even three tags, paired
> or not, the user will always be able to just the easy way and
> use stand-alone for all types.
>
> -ys
>
>








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