Title: Message
Hi,
G廨ard'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廨ard
G廨ard 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
