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: 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" <christian.lieske@sap.com>

31/07/2002 13:05


        To:        xliff@lists.oasis-open.org
        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:gcatt@windows.microsoft.com]
Sent: Dienstag, 30. Juli 2002  19:10
To: Mark Levins/Ireland/IBM; Tony Jewtushenko  <Tony.Jewtushenko
Cc: xliff@lists.oasis-open.org
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
gcatt@microsoft.com   (425) 706-1592
Symptom and sign of Inner Peace: An  unmistakable ability to enjoy each moment...
-----Original Message-----
From: Mark Levins/Ireland/IBM  [mailto:mark_levins@ie.ibm.com]
Sent: Tuesday, July 30, 2002 3:18  AM
To: Tony Jewtushenko <Tony.Jewtushenko
Cc:  xliff@lists.oasis-open.org
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  <Tony.Jewtushenko@oracle.com>

07/25/02 06:33 PM


        To:         "xliff@lists.oasis-open.org"  <xliff@lists.oasis-open.org>
        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:tony.jewtushenko@oracle.com
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:

  1. Shall be comprised of small changes that would not  require re-certification of supporting tools or technologies
  2. Shall deprecate but not remove any features present  in the previous release.
  3. Shall increment the version number to the right of  the decimal point.
  1. May be comprised of significant architectural changes  that may require re-certification of supporting tools and technology.
  2. May delete features that were deprecated in previous  releases.
  3. Shall result in an increment to the version number to  the left of the decimal point.

--
Tony Jewtushenko    mailto:tony.jewtushenko@oracle.com
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



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


Powered by eList eXpress LLC