Re: [xliff] Migration Policy Document

Mark:

Good suggestion.   Unless there's no objection,  I'll edit
the policy as suggested.

Any further issues or comments?

Regards,

Tony

 

 

Mark Levins/Ireland/IBM wrote:
 

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

 

--

Tony Jewtushenko    mailto:

Sr. Tools Program Manager   direct tel: +353.1.8039080

Product Management - Tools Technology Team

Oracle Corporation, Ireland

 

Attachment:
Tony.Jewtushenko.vcf

Description: Card for Tony Jewtushenko