[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". -yvesTitle: 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
In progress.
This topic was featured in several different threads of discussions: Interoperability, use of other standards, Eric's proposal, Christian's questions list, etc.
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>
).
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.]
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:
<prop-group>
and <context-group>
(and <prop>
, and <context>
).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:
ts
attribute.<prop>
element.Some useful references:
Namespaces in XML:
http://www.w3.org/TR/1999/REC-xml-names-19990114Email on the existence for data type/category for localization:
http://lists.oasis-open.org/archives/xliff/200205/msg00018.htmlNorman Walsh's article on XML vs. SGML DTDs:
http://www.xml.com/lpt/a/98/07/dtd/index.htmlXML Schema - Part 0: Primer
http://www.w3.org/TR/xmlschema-0/XML Schema - Part 1: Structures
http://www.w3.org/TR/xmlschema-1/XML Schema - Part 2: Datatypes
http://www.w3.org/TR/xmlschema-2/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC