RE: [xliff] Current XLIFF schema

[Doug Domeny <ddomeny@ektron.com>]

Shigemichi Yazawa,

Thank you for your comments.

Converting XHTML tags to <g ctype="tagName"...> would be time consuming.
Many values for 'ctype' would need to be added. There are more than just a
few tags.

XLIFF editors should simply ignore unknown tags. If new XLIFF tags are added
to the standard, then existing XLIFF editors should still work. This means
they should ignore unknown (newer) XLIFF tags.

In XML it is possible to add a namespace prefix without changing the meaning
of the tag. For example, <xlf:source> and <xlf:g> are the same as <source>
and <g> assuming that the xlf namespace is properly defined.

Do most XLIFF editors properly handle the namespace prefix or do they parse
the tag name assuming there is no prefix?

Regards,

Doug D

Ektron, Inc.
+1 603 594-0249
http://www.ektron.com


-----Original Message-----
From: Shigemichi Yazawa [mailto:yazawa@globalsight.com]
Sent: Tuesday, December 17, 2002 2:52 AM
To: Doug Domeny
Cc: XLIFF
Subject: Re: [xliff] Current XLIFF schema


At Wed, 11 Dec 2002 09:26:51 -0500,
Doug Domeny wrote:
>
> Of particular interest is extensibility of the TextContent to allow
> non-XLIFF tags, for example XHTML tags. I'm working on an application that
> includes XHTML tags, (like P, H1, TABLE), in the content. This is not to
say
> that every application would need to support XHTML, only that an
application
> could. Some tags, like A (hyperlink) and IMG, are converted to XLIFF G
> (placeholder) tags so that the translator is not exposed to URLs.

In this case, I would say, convert <p> to <g> as well. The idea here
in <source> and <target> elements is to make the text abstract so it
can be treated in a uniform way in an editor or as a TM segment
regardless the original file format. User defined tags here will have
a significant impact on the interoperability of XLIFF docement.

----------------------
Shigemichi Yazawa
yazawa@globalsight.com