I have some concern about the use of
the phrase 'unknown tags' or 'unknown markup' as I think they cause some
confusion. I think they may imply 'non-XLIFF tags', regardless of XLIFF
version and these cannot occur outside of our defined extension points
(using alternate namespaces).
I see two cases of 'unknown tags':
1. Tags unknown to a tool in a XLIFF
document for which the tool was designed, e.g. a tag inserted in XLIFF
at a point where extension is not allowed.
In this case unknown tags should not
be preserved as the tags are not valid XLIFF, nor constitute a valid part
of an XLIFF document and never will.
and
2. Tags unknown to a tool but which
are valid for a later version of XLIFF.
Therefore I suggest that the two directives
be changed to
"For files created with and complying
to a later version of XLIFF, tools must preserve unknown elements in that
file"
"For files created with and complying
to a later version of XLIFF, tools must not delete data that they do not
understand"
Regards,
Mark
"Lieske, Christian" <>
31/07/2002 13:05
To:
cc:
Subject:
RE: [xliff] Migration Policy Document
Hi,
Gérard's analysis is excellent.
From what I can see, the issue as well touches our
general thoughts on 1.1 and on conformity
because of the following:
For 1.1, we could envision a new data category along
the lines of
<xliff version="1.1" retainUnknownMarkup="yes">
Next, we could use a conformance statement (cf.
http://www.w3.org/TR/2000/REC-xml-20001006#sec-conformance)
to distinguish between different types of XLIFF processors
which differ wrt. the following capabilities:
a) validation
b) handling of extensions (additional/private namespaces)
c) retention of unknown markup
Best,
Christian
-----Original Message-----
From: Gerard Cattin des Bois [mailto:]
Sent: Dienstag, 30. Juli 2002 19:10
To: Mark Levins/Ireland/IBM; Tony Jewtushenko <Tony.Jewtushenko
Cc:
Subject: RE: [xliff] Migration Policy Document
Hello Mark,
You do have a good point.
In addition, we were also trying to determine how
to sift thru additional tags that may be there from other tools/namespaces
and removing them would hurt the workflow process in particular nodes
in the food chain.
So, I see two discussions threads here: one the
need to clearly validate an XLIFF file, and second, the need to process
an xliff file without cleaning it up of unknown tags.
We were thinking about exposing explicitly those
unknown tags via a private or public namespace so validation could
still take place. This, however does not address the second issue,
thus the statement to be able to retain those unknown tags from older
tools/scripts using xliff data.
THis issue is also related to extensibility which
Yves is driving.
Thanks,
-Gérard
Gérard Cattin des Bois
Lead Program Manager, LocStudio Services
Windows Productivity Tools Team
(425)
706-1592
Symptom and sign of Inner Peace: An unmistakable
ability to enjoy each moment...
-----Original Message-----
From: Mark Levins/Ireland/IBM [mailto:]
Sent: Tuesday, July 30, 2002 3:18 AM
To: Tony Jewtushenko <Tony.Jewtushenko
Cc:
Subject: Re: [xliff] Migration Policy Document
Hi Tony,
I've just one problem wrt the 'Cross-release compatibility
guidelines' section. In this section you state that "Tools must
not delete data that it does not understand" and "Tools must
preserve unknown elements in the file". If a tool is validating,
using either Schema or DTD, these comments cannot be applied if the
version of the XLIFF in the file is later than the tool supports
or if the tool uses an earlier Schema or DTD.
Perhaps the addition of something like "Tools
should not try to validate later versioned XLIFF documents"
might suffice.
Regards,
Mark
Tony Jewtushenko <>
07/25/02 06:33 PM
To:
"" <>
cc:
Subject:
[xliff] Migration Policy Document
I've revised the document based on discussions
over the past two
meetings.
Please reply with your comments by next Tuesday
- if no major
contentious issues remain by then, I will
draft and distribute an email
ballot to approve the policy.
Regards,
Tony
--
Tony Jewtushenko mailto:
Sr. Tools Program Manager direct tel:
+353.1.8039080
Product Management - Tools Technology Team
Oracle Corporation, Ireland
XLIFF 1.1 W.I.P. – 1.0 to 1.1 Migration Policy
Version Information:
Version
Date
Author
Description
1.0
11 June 02
Tony Jewtushenko
Initial Document
1.01
24 July 02
Tony Jewtushenko
Revisions based on 23 July 2002 TC Meeting.
Document Conventions:
The document is coded in the following way (adhering
to Peter Reynolds's document convention):
Greenif there is agreement
Navy if more discussion is needed
and redif it is contentious.
Where I have made a change I have emphasised the
changed word.
Migration Policy Proposals:
Rules for Major vs. Minor releases:
Support for Existing Users:
Rules for Name Changes:
Impact of Migration on Users Organisations:
Cross-release Compatibility Guidelines:
User Migration Assistance
Marketing, Public Relations and Education:
Rules for Major vs. Minor releases:
The Technical Committee will evaluate each individual
release and classify it as "Major" or "Minor"
release.
As a guideline, "Minor" releases:
Shall be comprised of small changes that would
not require re-certification of supporting tools or technologies
Shall deprecate but not remove any features present
in the previous release.
Shall increment the version number to the right
of the decimal point.
As a guideline, "Major" releases
May be comprised of significant architectural
changes that may require re-certification of supporting tools and
technology.
May delete features that were deprecated in previous
releases.
Shall result in an increment to the version number
to the left of the decimal point.
In general, a Minor release will have stricter rules on
changes than Major releases: Minor releases usually be comprised
of small and superficial changes and bug fixes to an existing specification
rather than deep architectural changes, which would typically be
implemented only for Major releases.
Support for Existing Users:
Deprecated support for changed elements, values or attribute
names, at least until next Major version number revision.
Enumerated lists are a potential issue if they are closed.
Therefore, no 1.1 lists will be closed if they existed as open lists
in 1.0.
Rules for Name Changes:
Name changes to required elements and attributes will
be considered only if semantics change.
Impact of Migration on Users Organisations:
Where appropriate, the TC will audit food-chain migration
and compliance issues when deciding on architectural changes to 1.0.
The "food chain" describes the dependencies within related
organization. For instance translators for a localisation vendor company,
localisation engineers for the publishing company and software developers
are all different point on the food chain, and may be affected differently
by different types of changes.
Results of such an audit may influence the TC's release
and migration strategy.
Cross-release Compatibility Guidelines:
Tools designed to support Minor XLIFF releases should
provide backward compatibility for files that adhere to the same
major release specification. For instance, tools that support
version 1.1 files should be able to cope with 1.0
Tools designed to support XLIFF should not upgrade the
version of a file without either warning the user or requiring explicit
UI or command line setting.
Tools must not delete data that it does not understand.
Tools must preserve unknown elements in the file.
User Migration Assistance
A Migration Policy Statement will be published as section
of each specification.
A Migration guidelines white paper will be authored and
provided as a deliverable of each release.
A "Migration Support Kit" – containing
Whitepaper, Sample Files, and possibly sample XSLT's
- will be made available for download at the XLIFF TC website.
Marketing, Public Relations and Education:
Formal Marketing, Public Relations, and Education strategies
and plans shall be devised as part of the rollout of new releases.
#### Tony.Jewtushenko.vcf has been removed from
this note on July 30 2002 by Mark Levins
