RE: [xliff] Thoughts on custom namespaces for extensions

["Estreen, Fredrik" <Fredrik.Estreen@lionbridge.com>]

Hi,

I agree that there is not a big difference between a custom namespace extension and an optional XLIFF module from a pure technical XML perspective. The main difference is that we should never define a module that if used by one tool hinders another tool to properly process the core standard (and possibly a different set of extension modules). Or that prevent the original tool that made use of the module to again process the file despite other tools ignoring that module.

If we can specify that requirement for custom extensions I think extensions are fine however implemented. If we cannot require that, we should not allow extensions. In the case of the <meta-holder> extension model I think it would be straight forward to word the standard for that element and children / attributes so that we achieve this restriction. In the case of namespaces I'm not so sure. The validation becomes more error prone if you modify the content so that it is no longer valid according to the extension schema. This does not only apply to required elements but also for example references from extension elements / attributes to other extension elements or standard elements if Schema 1.1 co-constraints are in use in the extension for example. Perhaps it is just a matter of coming up with the right words to achieve this with namespaces, if so I see no problems doing it that way.

This last point is obviously something where we would need to take care when designing our standard extension modules so that we do not introduce these problems.

Another point that I think is important both for optional modules but also for third party extensions is to have clear rules on what information non supporting tools are required to preserve in the file. These rules will likely differ depending on where in the file the extension appear. One example of a thing that must be preserved would be data on the top file level like some unique ID / workflow state inserted to uniquely track a file. If such data is lost the whole purpose of the extension is broken, so if possible it would be best if tools could expect that to be preserved. On the other hand a custom attribute on an annotation in target should probably not have the requirement to be kept intact. That would most likely be a huge obstacle to interoperability.

So in summary I'm fine with properly constrained extensions and feel it is easier to achieve with the <meta-holder> model. If the constraints can be place on extensions via namespaces I'm fine with them too. I'm strongly against the unconstrained extensions we currently have in 1.2.

Regards,
Fredrik Estreen

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: den 18 april 2012 11:45
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Thoughts on custom namespaces for extensions

> -----Original Message-----
> From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] 
> On Behalf Of Yves Savourel
> Sent: Wednesday, April 18, 2012 1:26 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Thoughts on custom namespaces for extensions

Hi,
 
> If extensions are only used to implement features not defined by XLIFF 
> they are no more of a threat to interoperability than modules.

Extensions are a threat, as they are not documented and require reverse engineering to achieve minimal interoperability. We can see today the interoperability disaster generated by extensions.

 
> So there are two questions:
> 
> 1) Should we allow extensions in XLIFF 2.0?

I would say no. Users also said no in the first symposium.

 
> 2) If the answer to 1) is yes, then should we use <metadata> or custom 
> namespaces to implement extensions?

If the TC agrees on allowing extensions, I prefer <metadata> or any element set defined by the TC.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org