RE: [xliff] OASIS guide to writing a conformance clause

["Magnus Martikainen" <MMartikainen@sdl.com>]

Hi all,

Another thought on this topic: Custom elements is just one part of what
would be expected to be preserved during processing of an XLIFF document
by tools that are 'compliant'. 

For example if the <skl> element or content is not preserved exactly as
it were there will likely be trouble. The same probably applies to
almost all things outside of a <trans-unit>, and even to some things
inside it (e.g. <source> content).

It may in fact turn out to be easier to define what NEED NOT be
preserved during processing of XLIFF files by 'compliant' applications. 

This would be very useful to have, however I think that it will take
significant efforts to properly research and define this.

Given that we want to get 1.2.1 out the door soon I would propose that
we leave the application compliance undefined and focus on file
compliance only, with a view to properly define application compliance
in scope of XLIFF 2.0.

Regards,
Magnus

-----Original Message-----
From: Doug Domeny [mailto:ddomeny@ektron.com] 
Sent: Wednesday, July 22, 2009 11:14 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] OASIS guide to writing a conformance clause

Rodolfo,

I like the new proposed paragraph and would include part b) even if we
decide applications must preserve custom extensions. The redundancy
stresses its importance and more obvious to the casual reader.

If a processing tool removes custom extensions, then it will almost
certainly cause a failure downstream when the tool that initially
inserted the extensions processes the modified XLIFF file without them.

A processing tool can remove custom extensions that it understands, but
must retain unknown extensions.

Regards,
Doug

-----Original Message-----
From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com] 
Sent: Wednesday, July 22, 2009 9:43 AM
To: xliff@lists.oasis-open.org
Subject: Re: [xliff] OASIS guide to writing a conformance clause

On Wed, 22 Jul 2009 09:12:16 -0400
"Doug Domeny" <ddomeny@ektron.com> wrote:

Hi,


> I agree that the last (unwritten) part about accepting XLIFF files
> generated/processed by other tools is difficult.

Perhaps we should separate generated from processed. The part
that deals with processed could be something like:

   XLIFF is a format explicitly designed for exchanging data. Thus, a
   conformant XLIFF application MUST be able to accept XLIFF files it
   generated after those XLIFF files have been processed by a different
   tool, provided that: a) processed files are conformant XLIFF
   documents and b) any custom extension added by the originating tool
   has been preserved.

> With this in mind, I would suggest rewording " conformant applications
> SHOULD preserve existing custom extensions " to " conformant
> applications MUST preserve existing custom extensions ".
 
At first, I agree with your proposal. It would make the b) part of the
proposal I wrote above unnecessary. However, I'm not sure about this.

Regards,
Rodolfo
-- 
Rodolfo M. Raya <rmraya@maxprograms.com>
Maxprograms http://www.maxprograms.com

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  Registered number: 02675207.  
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.