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] | [Elist Home]


Subject: RE: [xliff] Current XLIFF schema. Converting XHTML to XLIFF.


Yves and others,

It seems to me that there are really two distinct XML vocabularies.

1) XLIFF which is the structure or framework used to transport the content.
This part is really the interchange file format. It is extensible with
optional "any" attribute and elements allowed throughout the structure as
long as the namespace is different. Here the specification acknowledges that
it does not cover all possible uses for XLIFF. Even though XLIFF is for
interchange between disparate systems, it allows for system-specific
extensions that survive the round-trip.

2) The second vocabulary is for the content itself. This specification is
closed and minimalistic. It does not include extensibility, presumably
because the content editors are implemented only for the small set of
placeholder tags. This also implies that new tags cannot be added to the
specification without causing problems to the editors. It appears to me that
this part of the specification is very similar to the TMX tags for content.

This is my mental model of how the translation process works. My background
is as a user of translation services, not a provider. As I see it, the XLIFF
data will be passed to an XML processor to extract the <source> and pass it
to an editor for translation. That editor is not completely XLIFF aware, but
knows only the few tags allowed within <source> and <target> elements, for
example, <g> and <ph>. Once the translation is done, the content is
re-packaged by an XML processor to return the XLIFF data back to the
recipient.

XLIFF data <---->  XML processor extracts content <----> content translation
(allows only a few tags)

Please let me know if I am misunderstanding it.

To convert any XHTML tag to <g> or other appropriate XLIFF tag, the values
for the 'ctype' attribute would have to be either open-ended, allowing any
value, for example, ctype="textarea" or have a predefined value, like
"other", that would be generic. For example, I would need to convert XHTML
paragraphs (<P>) and tables (<TABLE><TBODY><TR><TD>) to <xlf:g> elements.

This is how I converted hyperlinks (A) and images (IMG) to XLIFF.

<xlf:source>Enter the body text of your <xlf:g ctype="link"
id="IDA5A4R">XHTML</xlf:g> document here <xlf:g ctype="image"
id="IDAGB4R"></xlf:g>
</xlf:source>
<xlf:target>...</xlf:target>
<xlf:prop-group name="IDA5A4R">
	<xlf:prop prop-type="tag">
		<a href="http://www.w3.org/xhtml"; target="_self" title="eXtensible
HTML"></a>
	</xlf:prop>
</xlf:prop-group>
<xlf:prop-group name="IDAGB4R">
	<xlf:prop prop-type="tag">
		<img src="fig1.gif" alt="fig one" width="11" height="21"
align="right"></img>
	</xlf:prop>
</xlf:prop-group>

Now that prop-group and prop are deprecated, I would use a custom namespace
element instead, for example:

<xlf:source>Enter the body text of your <xlf:g ctype="link"
id="IDA5A4R">XHTML</xlf:g> document here <xlf:g ctype="image"
id="IDAGB4R"></xlf:g>
</xlf:source>
<xlf:target>...</xlf:target>
<my:tag name="IDA5A4R">
	<a href="http://www.w3.org/xhtml"; target="_self" title="eXtensible
HTML"></a>
</my:tag>
<my:tag name="IDAGB4R">
	<img src="fig1.gif" alt="fig one" width="11" height="21"
align="right"></img>
</my:tag>

The <my:tag> elements store the original tag name and attributes. BTW, the
id values were automatically generated in an XSLT using the XPath function
generate-id().

Does this conform with the basic principle behind tagging content?


On a slightly different topic, I also have a proprietary vocabulary that I
use in the original XHTML document to indicate which parts should be
extracted to an XLIFF document for translation. The original XHTML document
is essentially an XLIFF skeleton (skl) file. I know there has been some
discussion of putting XLIFF tags into XHTML documents, but I did not see how
to apply them, so I can up with my own. I only needed two tags: <skl:text>
and <skl:block>. Each has a required 'id' attribute, which must be unique.
This would seem to be a third XLIFF vocabulary that applies to skeleton
files that are XML compliant.


I've only recently joined and I don't want to delay the specification
process. My hope is to be able to use XLIFF with original XHTML content in a
process that is automated as much as possible. I am willing to have these
discussions deferred to a more convenient time. Perhaps a case-study or
"best practices" document would help me. Do any exist yet for XHTML
applications?

Regards,

Doug Domeny

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


-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Tuesday, December 24, 2002 11:20 AM
To: XLIFF
Subject: RE: [xliff] Current XLIFF schema


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>


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



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


Powered by eList eXpress LLC