OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  Thoughts on custom namespaces for extensions

    Posted 04-17-2012 22:05
    Hi all, To follow up on the call's discussion about extension, here are two additional thoughts: === a) Using custom namespace willy-nilly: Fredrik mentioned a drawback of using custom namespace for extension that I didn't noted before: The ease of use of custom namespace may tend to encourage people to create their own namespaces left and right without much consideration for interoperability. That's a valid concern. But maybe this could be address, at least to some level, in a better way than in 1.2. We can have *conformance* rules regarding when and what types of extension one can have. For example, the recommendation we had in 1.2: "...it is strongly recommended to use XLIFF capabilities whenever possible, rather than to create non-standard user-defined elements or attributes." should be set as a specific conformance rule: - An extension MUST NOT implement an feature already represented in XLIFF. Also, in addition to specify where extension points would be, we could also add specific conformance rules for restricting potential problems. For example: - A custom namespace MUST NOT define a mandatory element that is directly the child of an XLIFF element. - A custom namespace MUST NOT define a mandatory attribute in an XLIFF element. - etc. === b) Custom namespaces and XLIFF modules Another important aspect to this discussion is how exactly XLIFF optional modules are handled by tools not specifically implementing them. I see that as important because in many aspects a custom namespace is a lot like an optional module. It seems most of the expectations we would have for optional modules in general could apply to custom namespaces as well: whether a tool MAY/SHOULD preserve them, etc. Cheers, -yves


  • 2.  Re: [xliff] Thoughts on custom namespaces for extensions

    Posted 04-17-2012 23:12
    Hi Yves, 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. Modules are not a threat to interoperability, custom namespaces are. Regards, Rodolfo Sent from my iPad On Apr 17, 2012, at 7:04 PM, Yves Savourel <ysavourel@enlaso.com> wrote: > Hi all, > > To follow up on the call's discussion about extension, here are two additional thoughts: > > > === a) Using custom namespace willy-nilly: > > Fredrik mentioned a drawback of using custom namespace for extension that I didn't noted before: The ease of use of custom namespace may tend to encourage people to create their own namespaces left and right without much consideration for interoperability. > > That's a valid concern. > > But maybe this could be address, at least to some level, in a better way than in 1.2. > > We can have *conformance* rules regarding when and what types of extension one can have. > > For example, the recommendation we had in 1.2: "...it is strongly recommended to use XLIFF capabilities whenever possible, rather than to create non-standard user-defined elements or attributes." should be set as a specific conformance rule: > > - An extension MUST NOT implement an feature already represented in XLIFF. > > Also, in addition to specify where extension points would be, we could also add specific conformance rules for restricting potential problems. For example: > > - A custom namespace MUST NOT define a mandatory element that is directly the child of an XLIFF element. > - A custom namespace MUST NOT define a mandatory attribute in an XLIFF element. > - etc. > > > === b) Custom namespaces and XLIFF modules > > Another important aspect to this discussion is how exactly XLIFF optional modules are handled by tools not specifically implementing them. > > I see that as important because in many aspects a custom namespace is a lot like an optional module. > > It seems most of the expectations we would have for optional modules in general could apply to custom namespaces as well: whether a tool MAY/SHOULD preserve them, etc. > > > Cheers, > -yves > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: xliff-help@lists.oasis-open.org >


  • 3.  RE: [xliff] Thoughts on custom namespaces for extensions

    Posted 04-18-2012 04:26
    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>. Cheers, -yves


  • 4.  RE: [xliff] Thoughts on custom namespaces for extensions

    Posted 04-18-2012 09:45
    >
    Original Message


  • 5.  RE: [xliff] Thoughts on custom namespaces for extensions

    Posted 04-18-2012 13:05
    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


Related Content