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: [xliff-comment] Public Comment

-----Original Message-----
From: Doug Domeny [mailto:ddomeny@ektron.com] 
Sent: Monday, February 13, 2006 10:33 AM
To: 'rodolfo@heartsome.net'; 'xliff-comment@lists.oasis-open.org'
Subject: RE: [xliff-comment] Public Comment


Thank you for your comments and feedback. I have wondered whether using
namespace prefixes would be a problem with some of the tools. The XLIFF 1.1
documents I've created have used the xlf: prefix. For *internal* use, I've
embedded XHTML in the XLIFF documents, and using the xlf: prefix
distinguishes between XLIFF and XHTML for validation. In practice, when
sending XLIFF to translation services, I've sometimes needed to down-rev to
XLIFF 1.0 without the namespace prefix.

I understand that parsing XML without using a standard XML parser is made
more complicated when namespace prefixes are used. Even with standard XML
parsers, namespace declarations are difficult to manage. For example, if the
XLIFF document contains no namespace declaration at all verses declaring a
default namespace.

Default namespace typically requires passing the namespace to the XML

<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1">

No namespace declaration typically requires NOT passing a namespace to the
XML parser.


To make matters even more complicated, the default namespace may change.
Child tags inherit the namespace of the ancestor element with the namespace
declaration. Fortunately, I haven't seen this done very often. For example,

<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1">
	<group resname="BookTitle" datatype="xml">
		<skeleton xmlns="http://www.w3.org/1999/xhtml";>
			<p><em>XML Internationalization and

The tags belong to the following namespaces.

xliff          urn:oasis:names:tc:xliff:document:1.1
group          urn:oasis:names:tc:xliff:document:1.1
skeleton       http://www.w3.org/1999/xhtml
p              http://www.w3.org/1999/xhtml
em             http://www.w3.org/1999/xhtml

I write a fair number of XSLTs and namespaces are a routine problem.
Essentially, an XSLT can be written for just one root namespace (or no
specified namespace). Fortunately, the prefix doesn't matter, but
transforming an XLIFF with no namespace or the 1.1 namespace or the 1.2
namespace would require three different transforms. (Reference: "XSLT: XPath
select statements do not match XML or XHTML with a default namespace"

However, use of a namespace prefix is not so much a matter of the XLIFF
specification as it is the XML specification. The use of namespace prefixes
is implied in the XLIFF specification because it is XML. That is, prefixes
may be used or not and any prefix may be used and still be valid XLIFF 1.1.

For example, all these are perfectly valid XLIFF 1.1 snippets. 

<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1">

<xlf:xliff xmlns:xlf="urn:oasis:names:tc:xliff:document:1.1">

<xliff11:xliff xmlns:xliff11="urn:oasis:names:tc:xliff:document:1.1">

<a:xliff xmlns:a="urn:oasis:names:tc:xliff:document:1.1">

Having said all this, it's advisable to state in the specification the
practical realities and limitations to be functionally compatible. 

However, it would be prudent for consumers of XLIFF to support the XML
standard for namespaces. Especially given that the standard is moving in the
direction of allowing multiple namespaces within the XLIFF document, it's
only natural for people to want to apply a prefix to the XLIFF tags.

In summary,

The specification (and profiles) should recommend the following practices.

XLIFF Writers:

* Most compatible: Generate XLIFF without namespace prefixes. (For XLIFF
1.1, the default namespace declaration is required.)

* Somewhat compatible: Generate XLIFF with xlf: prefix.

* Least compatible (not recommended): Use of a prefix other than xlf:

XLIFF Readers:

* Minimally compatible: No support for namespace prefixes.

* Somewhat compatible: Support no prefix or the xlf: prefix.

* Most compatible: General support for XML namespace prefixes.

Tool vendors should state their limitations for namespace prefixes along
with their compatibility of XLIFF versions.

The similar thought applies to file name extensions. Really any extension
should be supported, but .xlf is recommended, with .xml also being quite

Doug Domeny
Software Analyst
Ektron, Inc.
+1 603 594-0249 x212
-----Original Message-----
From: comment-form@oasis-open.org [mailto:comment-form@oasis-open.org] 
Sent: Monday, February 13, 2006 8:44 AM
To: xliff-comment@lists.oasis-open.org
Subject: [xliff-comment] Public Comment

Comment from: rodolfo@heartsome.net

Name: Rodolfo M. Raya
Title: Director of Product Development
Organization: Heartsome Holdings Pte Ltd
Regarding Specification: XLIFF 1.1 / XLIFF 1.2

Today I received a file with this format:

<?xml version="1.0" encoding="utf-8"?>
<xlf:xliff version="1.1" xmlns:xlf="urn:oasis:names:tc:xliff:document:1.1">
  <xlf:file datatype="xml" original="source.xml" source-language="en">    
          <xlf:trans-unit id="1" datatype="xml">

By using a prefix in namespace declaration the names of the XLIFF elements
are altered. This is a complication for tools that support XLIFF files and
relay on standard element names instead of fully qualified names.

XLIFF specs do not mention the use of prefixes for the XLIFF namespace.
Which is the position of the XLIFF TC regarding this use of the XLIFF

Could an official recommendation or a best practise statement be added to
the XLIFF 1.2 specs?

Best regards,
Rodolfo M. Raya

To unsubscribe, e-mail: xliff-comment-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-comment-help@lists.oasis-open.org

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