RE: [xliff] Current XLIFF schema

[Yves Savourel <ysavourel@translate.com>]

Hi Doug and all,

I'm just getting back to work and trying to catch up with everything, so I
may speak without full understanding of the different discussions you all
had the past 2 month, but it seems this one is still going on.

My understanding of XLIFF content mechanism is that the format is meant to
separate text from codes, using a finite number of inline element that allow
to 'abstract' the original codes (regardless of their format).

It seems that allowing other elements of another namespace within the
content would break that basic principle. I understand that one might want
to do a lot of things with an XLIFF document at different stage, like edit
it. And using different namespaces in the content is very handy for this.
But, in my view, those are proprietary modifications of XLIFF (which can
certainly exist without conflict). I think the burden of go from the XLIFF
format to those extensions (and back) should reside in whatever tool use the
extension.

The mandate of XLIFF is to be an exchange format, and as it, in my view, it
cannot allow to have extension for the content.

Just my first impression on this topic. But I certainly think the subject
should be looked at carefully and the advantages (if any) of allowing
extensions in the content be considered.


kind regards
and Merry Christmas
-yves


-----Original Message-----
From: Doug Domeny [mailto:ddomeny@ektron.com]
Sent: Wed, December 11, 2002 7:27 AM
To: XLIFF
Subject: [xliff] Current XLIFF schema



Is the latest revision of the XLIFF schema available?

I would like to compare it with the one I am currently using. I made a
couple small changes/fixes before I joined OASIS and the XLIFF TC.

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.

EXAMPLE
:
<xlf:source>
	<p>Enter the body text of your <xlf:g ctype="link"
id="IDA4A4R">XHTML</xlf:g> document here</p>
	<xlf:g ctype="image" id="IDAFB4R"/>
	<p>second Enter the <xlf:g ctype="link" id="IDAOB4R">body</xlf:g> text of
your XHTML document here</p>
</xlf:source>
:

RECOMMENDATION

Add '<xsd:any namespace="##other" processContents="strict" minOccurs="0"/>',
as shown below, if it is not already present.

	<xsd:group name="ElemGroup_TextContent">
		<xsd:choice>
			<xsd:element name="g" type="xlf:ElemType_g"/>
			<xsd:element name="bpt" type="xlf:ElemType_bpt"/>
			<xsd:element name="ept" type="xlf:ElemType_ept"/>
			<xsd:element name="ph" type="xlf:ElemType_ph"/>
			<xsd:element name="it" type="xlf:ElemType_it"/>
			<xsd:element name="mrk" type="xlf:ElemType_mrk"/>
			<xsd:element name="x" type="xlf:ElemType_x"/>
			<xsd:element name="bx" type="xlf:ElemType_bx"/>
			<xsd:element name="ex" type="xlf:ElemType_ex"/>
			<xsd:any namespace="##other" processContents="strict" minOccurs="0"/>
		</xsd:choice>
	</xsd:group>

Many other tags are extensible, why not TextContent?

Regards,

Doug D

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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>