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: [xliff] Consolidation - Formalized Extensibility

Following up on the action item of last meeting, here is the consolidated
information on the topic "Formalized Extensibility".


Title: Formalized Extensibility

Formalized Extensibility

Last update: Jun-03-2002

1. Status After Meeting
2. Discussion
    2.1. Extensibility in XLIFF 1.0
    2.2. Proposals for Extensibility in XLIFF 1.1
    2.3. Meeting Consensus
3. Additional Information

1. Status After Meeting

In progress.

2. Discussion

This topic was featured in several different threads of discussions: Interoperability, use of other standards, Eric's proposal, Christian's questions list, etc.

2.1. Extensibility in XLIFF 1.0

In XLIFF 1.0 user-specific data can be inserted using the <prop> element (in a <prop-group>) and using the ts attribute in some elements. Another element is also related to user-specific data: the <content> element (in a <context-group>).

2.2. Proposals for Extensibility in XLIFF 1.1

One aspect of extensibility we discussed was to be able to define new values for attributes, in addition to XLIFF-pre-defined values. Christian and Gérard described the way TBX was allowing such extensibility. This for example involved the Data Category standard (ISO 12620). John C, mentioned some existing mechanisms in schemas may be more standard.

Yves noted that new attribute values may cause interoperability problem if they override existing XLIFF standard values: Imagine an XLIFF standard value for datatype to be "java-properties". If a tool extends the list of values for datatype to include "java-resource-list" and "java-resource-bundle" to make a distinction between how the data are stored, tools that provide functionality based on datatype may not work anymore. To solve this, not only a formal mechanism would need to be defined to extend an value list, but some rules and/or guidelines would need to be established as to how the extended values relate to possible XLIFF existing ones.

The need to allow to use other XML vocabularies into an XLIFF document, using the namespace mechanism, was also discussed. The notion of "private" and "public" namespaces was mentioned. [YS: I'm not sure what was the difference made between a "private" and a "public" namespace (there are no such distinction in the Namespaces in XML W3C's Recommendation). I assume the first is proprietary and not publicly available while the second is publicly available, like XHTML.]

2.3. Meeting Consensus

The meeting proposed that we create a schema based on the refinements to version 1.0. It was discussed and agreed that whatever can be implemented from Eric and Colin's proposal will be implemented, but the TC will not adopt the proposal in its entirety due to the magnitude of the changes. However it was agreed that the following interoperability proposals will be discussed for implementation within 1.1 specification:

3. Additional Information

The location were extensions would be allowed would be specified in the XLIFF schema. For example, not all attributes would have an extensible list of values and not all elements would contain elements of other namespaces.

A simple way of allowing extensibility (using namespaces) based on the current version, would be to:

Some useful references:

Namespaces in XML:

Email on the existence for data type/category for localization:

Norman Walsh's article on XML vs. SGML DTDs:

XML Schema - Part 0: Primer

XML Schema - Part 1: Structures

XML Schema - Part 2: Datatypes

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

Powered by eList eXpress LLC