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] | [List Home]

Subject: RE: [xliff] Thoughts on custom namespaces for extensions

Hi Rodolfo, all,

> A module is not the same as a custom namespace.
> A module is public and documented. Everybody would 
> be able to implement support for official modules
> if desired.

It does not matter how public or well documented a module is, if a tool does not implement a module (since all modules are optional) then that module is like a custom namespace for that tool.

For example, Tool A does not implement <matches>. When it opens a document with <matches> what processing expectations can be ask of Tool A?

My understanding is that tools should preserve elements/attributes they do not 'understand'. Consequently I would expect Tool A to do its business while preserving the <matches> elements, then output the modified document with the <matches> as intact as possible.

If that is the expected behavior for a tool with regard to the official XLIFF modules it does not support, then the same tool should have no problem preserving custom extensions as well.

At that level, the only interoperable aspect is passing the unknown data as-it to the next tool. Both the  unsupported modules and the custom namespace can be handled the same way.

> Modules are not a threat to interoperability,
> custom namespaces are.

Custom namespaces are not a thread to interoperability, extensions are the potential threat.
I keep seeing emails mixing both concepts, so let's define them once again:

- Extensions are custom data not defined by XLIFF.

- Custom namespace is one of the two possible ways to implement extensions, the other is <metaHolder>.

Extensions are the same threat to interoperability whether they are implemented with <metaHolder> or custom namespaces. And that threat is not coming from the mechanism itself, it's coming from how people use it.

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

So there are two questions:

1) Should we allow extensions in XLIFF 2.0?
I think it would be a major shortcoming of 2.0 if we do not. 

2) If the answer to 1) is yes, then should we use <metadata> or custom namespaces to implement extensions?
To me, custom namespaces have far more advantages than drawbacks when compared to <metaHolder>.


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